IPTEL, IETF 48 -------------- Minutes taken by: Flemming Andreasen Hussein Salama Minutes Edited by: Jonathan Rosenberg IPTEL met for a single 2.5 hour session during IETF 48 in Pittsburgh. Agenda ------ * Agenda bashing * CPL open issues, Jonathan Lennox * TRIP ope issues, Hussein Salama * TRIP-GW update, Jonathan Rosenberg * transit networks in TRIP, Dave Walker * H.323 URL, Orit Levin * Service Routing, Jonathan Rosenberg CPL Open Issues --------------- Jonathan started by describing the changes in revision 2 of the CPL specification. THe main changes were: Changes * Time handling reworked: matches iCal * H.323 mappings * XML and MIME types * New string switches: language , display * Enhancements of Node Time handling was the biggest change: +++++++++++++++++++++++++++++++++++++ * moved from crontab format to iCal (RFC 2445 - Proposed Standard) * makes it easy to create CPL srcitps automatically from calendars * rich syntax * complicated to evaluate (interoperatbility problems reported, some bugs in spec) Jonathan expressed concerns about complexity - was it really worth it? He asked for pseudo-code implementation to see implementation feasibility and ambiguity. Are there translation problems between formats (e.g. calendar to iCal). Long term we probably need the capabilities it provides us with, but really need to implement and see that it works unambigously. Don't want to have lots of different formats (SDP, iCAL, something else) Further time change: time zones. ++++++++++++++++++++++++++++++++ Time zones also derived from 2445. Time-switch nodes have two new attributes: * tzid (time zone identifier: server-local or from a to-be-defined IANA registry) * tzuel (time zone URL: reference to a RFC 2445 VTIMEZONE) VTIMEZONE is basically the same (semantic) rules as new time definition Work is (slowly) in progress to create an IANA iCal timezone registry based on the Olson TZ database. Jonathan Rosenberg (JR): Is this (iCal) really going to happen ? Real problem that people in different tz. wants to upload CPL scripts and if iCal doesn't happen we then don't have nothing. Henning Schulzrinne (HS): We don't have anything else realistically. Even Windows uses something similar. JR: There needs to be pseudo-code to show how to do this. If we get that, then we will continue with this proposal. JR: As for timezone, sync up with iCal people - we need something that works now (consensus on this) Another change: H.323 bindings: address types +++++++++++++++++++++++++++++++++++++++++++++ * Mappings defined for H.323 address types. * H.323 has addresses both in Q.931 part and H.323 UUIE part. Not clear which one takes precedence, but server should use same rules for CPL as it uses for routing. Orit Levin: Complicated issue in H.323 (there are other compl. issues in H.323 as well). Shouldn't this be done in conjunction with the H.323 community. Jonathan Lennox (JL): Tried doing it on the list. Orit: Annex O work to begin in SG-16 in two weeks (looking at Internet). Should submit this to SG-16 and ask for feedback. JR: Prepare a list of questions to SG-16, give to Orit for resolution. Specific H.323 mappings * H.323 alias address have ~8 different possible formats * Define mappings for each of these into CPL address subfields (done) * also define new alias-type address subfield for H.323 servers * Based on H.323v4, to be publishd in November; introduces H.323 URL scheme. Is this a problem for last call ? OL: Once you have H.323 URLs, why would you want to take the URL apart and map into different address subfields JL: Because we still have the old stuff around. OL: Some more comments about mapping concern between H.323 and SIP (addresses and messages) OL: SG-16 should talk about how to use H.323 with CPL (better qualified) JL: Agreed that there should be joint work here. If ITU wants to help then fine; we have been asking for their input for a while. It was agreed that we would not hold up CPL waiting for the H.323v4 or H.323 URL work. Scott confirmed that a proposed RFC cannot have normative references even to other standards work that is not complete. So, H.323 URL and other newer stuff will be relegated into an optional appendix. Another change: Mime Registration +++++++++++++++++++++++++++++++++ Added MIME registration section Media type application/cpl+xml Conforms to format of XML types in draft-murata-xml-06.txt. Another change: Parameters, considereations, file extensions ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Specified XML public identifier "-//IETF Specified XML namespace "http://www.ietf.orginternet-drafts/draft-ietf/iptel-cpl-02.txt" to be "http://www.rfc-editor.org/rfc/rfcxxxx.txt" when we go to RFC New string-switch fields ++++++++++++++++++++++++ New string-switch field: language. This is the language caller wants to receive. display-field: corresponds to Q.931 display IE Changes to location nodes +++++++++++++++++++++++++ Documented attribute clear of location and lookup nodes. * Is this really ncessary, given remove-location location ="*" changes to proxy and reidirect nodes ++++++++++++++++++++++++++++++++++++ added output redirection to proxy nodes Other changes ++++++++++++++ * Weakened server support for scripts that do not conform to the DTD from SHOULD to MAY * Clarifications * More examples * DTD updated Todo and proposed enhancements * Add q parameter to location nodes (needed for priority order) * Draft asserts H.323 has no equivalents * Clarify how extensions should work: XML namespaces. * Complaints about default timeout value for proxy being dependent on whether noanswer output is present or not. Jonathan R. initially raised this concern but has relented, as it makes the most sense. So, we will specify that the default timeout value is dependent on the presence of noanswer. HS: So where are we ? Ongoing implementations, not a lot ofoperational experience, let people go home and code. Recommend be last IETF presentation before Last Call. May not be the final answer for CPL, but should suffice for version 1.0 HS: Related work: currently non-overlapping, but may change: Voice-XML. Two concepts from vXML to look at (didn't catch what they were, variables (?) ). JR: Agreed. Fix up the H.323 and timezone stuff. No more presentations. Namespaces allow us to add stuff later. OL: Who is going to implement the H.323 stuff and verify it. JR: We can leave it in there. If nobody implements, then can remove before going go Draft Standard. Soliciting input from H.323 community, have done for 1+ year, continue to do, don't know what more we can do. OL: What if it turns out that changes are needed to be suitable for H.323 JR: We'll have to see what the outcome is. Scott Bradner (SB): Can always modify and recycle as Proposed Standard if changes needed JR: Better to get it before going to Proposed. HS: Let's set a deadline for people to move forward JL: what about H.323 URLs SB: can't be a normative reference if still not a standard (H.323v4). Move reference to an appendix. Can always move back when H.323v4 solid. TRIP Open Issues ---------------- Hussein Salama Hussein Salama prsented the recent changes and Open Issues for TRIP. Next Hop Server Format ++++++++++++++++++++++ * Comment from Adelaide: to represent the next hop server by domain name or IP address in DNS format * Open issue: Transport type: UDP/TCP (proxy.ietf.org.transport-tcp).. do what SIP does. * Open issue: Representation of IPv6 addresses in TRIP. JR: Do what SIP does for transport; for IPv6, there is an rfc that defines the representation of IPv6 inside of URLs, which works for us. Capabilities ++++++++++++ * Currently: route types supported and Send Receive Capability * IANA considerations * Reserved capability code 0 * Capability codecs 32768 to 65535 for vendor-specific capabilities * Open Issue: making "route types supported" mandaty E.g. may only be interested in SIP or H.323 routes. * Open Issue: adding "Capability Mismatch" error code Communities Membership Capability ================================ Based on BGP communities Permits an LS (Location Server) to announce to its peer the communities it is interested in. The peer then only advertises to the LS routes of those communities. Attribute Type Codes ==================== Assigned type codes to all attributes. IANA considerations. Reserved type codes 224 to ? Application Protocols ===================== Added two new apl. protocols RAS and H.323 Annex G. Address Families ================ Letters other than 10 digits used in Europe. Had to deviate from IANA's standard set of address families. Define two address families * POTS numbers: private, local, national, and internation (0-9) * routing numbers: mainly for European LNP (0-9, A-F) IANA considerations May want to deifne other address families in the future, e.g. URL. ITAD numbers ============ Reserved ITAD numbers 0 and 65535 ITAD numbers 64512 to 65534 are for private use IANA considerations Proposal: Use domain names instead of ITAD numbers. Issues: * No need for IANA registration * ITAD topology restrictions * Effect on AdvertisementPath and RouterPath attributes (domain name would imply long attribute names) SB: Running into trouble with 16-bit fields for AS. Change to something bigger for ITAD. MED and Tie Breaking Rules ========================== Removed inconsistency * MED usage consistent. Higher MED is preferable * Changed tie breaking rules to favor internal routes over external routes Secuurity considerations ======================== Protection of peer sessions using IPSec * Transparent mode security association * Either AH or ESP Protect route itself over multiple hops: * Sign critical attributes of the route * Include list of signatures in Authentication attribute. If intermedia changes, must remove signature and resign itself * Open Issue: What signature mechanism to use ? UPDATE Rate Limiting ==================== not yet updated (Adelaide issue - check) Application Protocol Manipulation ================================= ex: receive SIP route, want to advertise as Q.931 route. Not manipulating an attribute, really chaning the route, not really comfortable with this, what could be the possible side-effects be ? JR: Difference between this and TRIP is that TRIP is an app protocol Jon Peterson: Concern about feature transparency loss due to translation (wouldn't be visible from routing info). JR: Maybe there's another attribute needed to signal whether transparency loss may result. Hussein: Could add an attibute similar to what we do for route aggregation JR: OK, consensus is to add that to the spec. Multiple TRIP Ids per LS ======================== An LS MUST use the same TRIP ID with all internal peers. Question: what's the significance of TRIP ID between external peers. Can we have a different TRIP ID with different external peers? JR: In the interest of KISS, since we can't think of a reason to do it, just keep as single ID (consensus) ITAD boundaries =============== follows BGP model. Two possibilities: * On the link between two LSs * On the LS itself. Splits the LS box into two (or more) virtual LSs. Permits route summarizatioin of TRIP-Lite routes. Allows integrating TRIP-Lite with TRIP. No changes to protocol seems to be required. Seems straightforward - would like to allow it. JR: Work has been going on for a while. Only minor stuff remains. Finish off for next meeting (similar to CPL). TRIP for Gateways (TRIP-LITE) ----------------------------- Jonathan Rosenberg Got mixed feedback in Adelaide, want to convince everybody it's a good idea. Gateway Management Problem: need a way to manage routing of calls to heterogenous gatewasy within service provider * Depends on liveness * Depends on availability (capacity, etc.) * Depends on matching capabilities of call * codecs * extensions * Depends on cost of termination Can TRIP be used ? TRIP provides routing exchange inter-domain Very similar problem * keepalives * prefix propagation * attributes and capabilites Scope of information restricted due to scale Scale issues different intra-domain * Can add additional information needed to support GW management * Can update information more frequently Thus, need a profile of TRIP TRIP-GW Not a new protocol Profile of TRIP * Used particular components * No aggregation or redistribution - that's normal TRIP * Additional attributes for this configuration SB: It really shouldn't be called anything saying TRIP (marketing confusion). Profiles are a way to say that the original protocol was to complicated. Call it something else Jon Peterson: Are you sure you want to disallow aggregation? What if I want to build a complex intra-domain network with routes propagated and aggregated among LS's within the domain? JR: Well, then you are really entering TRIP territory. On the other hand not clear how that would work if you had a single ITAD number. Need to think a little more about it. Sinnreich: Helps avoid provisioning. Benefits of TRIP-GW Information readily exported to normal TRIP interdomain Allows rapid detection of gateway failures and rerouting Supports heterogenous gateway farms Huitema: Defining internal BGP for telephony and that's not a good idea. BGP is lousy for that. Really want to have some kind of special purpose. Doesn't seem like the right tool for the job JR: Has benefits beyond provisioning. HS: Not clear this is a good fit. SLP would seem a much better fit. Service discovery is what you want JR: Disagree - SLP is a pull mechanism. Want a push mecanism. HS: No. can do service advertisement (at a small scale) JR: Not convince SLP the right tool, e.g. keepalives HS: Disagree. May be that a service push protocol is needed, but really not clear that TRIP is the right choice. Sinnreich: Need to differ between architecturally correct solutions versus short term deployable mechanisms that may not be perfect, but are usable. WG proposal JR: Not consensus obviously. Think about the intra-domain routing problem. Two questions 1. Is this problem something we want to address. 2. What are the requirements? Rohan: Go ahead and use TRIP Orit: Really a problem. Hussein: Really two problems. Gateway registration, internal routing, external routing Jon Peterson: May want to have multi-criteria routing Radhika Roy: May not want to use TRIP. JR: Problem can be split into two: * Propagation of information to proxy from a gateway * Propagation of information between proxies JR: Consensus to adopt this problem as a working group item (not using TRIP, but looking at problem)? YES. Transit Networks ---------------- Dave Walker, SS8 TRIP distributes routes based on E.164 numbers Sometimes need to route based on carrier however. Transit network selection indicates (ordered sequence of) preferred carriers * Q.931 setup, ISUP IAM National identification plans * ANSI ISUP: 4 digits (0-9, B,C) administered by NANPA Why should this matter to IPTEL? In the near future, have to allow users access to both IP and PSTN based carriers. Could try to route to gateway nearest destination, then local PSTN call, but want to provide "best" route into the specified network. TRIP based solutions: Proposal 1 - New address family route on TN reagardless of dialed number (excl CAC) new database key value (currently POTS, RoutedNumber) * POTS, RN still advertised separately (useful if TN not selected) issue: call signaling may be sup-optimal * correct route may require both E.164… Proposal 2 - new attribute type TN is an optional attribute of E.164 ReachableRoute * flexible * reachign all E.164 (ie. "*") equivalent to new address family can use existing TRIP DBs with addition of new key issue: complexity * affects E.164 aggregation What's next chose best proposal ensure all national plans satisfied clarify intra- & inter-domain behavioral differences * e.g. does carrier prefer internal gw to TN over own external meet requirements of section 5.12 for new attribute specification describe use of TN is SIP-URLs Hussein: Three questions: * Why always have country-code as part of identifier. Answer: May look into that * Using attributes proposal: problem is you get two routes and TRIP would drop one of them. Answer: draft explains this. route selection would have to change * First proposal with separate AF. We would need to correlate them somehow. JR: This seems a clearcut case of a new attribute (your second proposal). Jon Peterson: Would be nice if you could like at the TRIP-GW problem. Dave: Draft just intended to introduce problem and get discussion going. Henning: Country code poor selection as many providers exist in multiple countries. Think about roaming. Dave: Many scary scenarios. E.g. if going to Europe and carrier is US, then may end up routing calls back to US. Can talk about all this stuff in a future draft. We agreed that the second proposal is better. However, the proposal requires more work, mainly in two areas: - specify how aggregation will work - specify how "searching the RIB" will be affected. Previously the two search keys were address and application protocol. Now the CIC attribute is a third search key. Significant change. H.323 URL --------- Orit Levin draft-levin-h323-url-scheme-00.txt Goals * publish H.323-URL definition as an Informational RFC * Register H.323-URL with IANA H.323-URL use A pointer to H.323 "service" * To be carried in H.323 messages * To be used in web-pages * etc. H.225.0 "Alias" Definition H.323 URL part of H.225.0 Alias H.323v4 to be decided in November. H.323-URL Syntax Have a definition proposed and would like to solicit comments URL can only have a user-part and a host-part. H.323 URL resolution not based on DNS resolution solely (obviously). Commonalties * The H.323 URL host portion is Case Insensitive * The host numbers are defined to be used without square brackets H.323 specific issues * GK identifier as a part of "host" portion (using UNICODE, so will probably have to restrict to ASCII use) Rohan: Any parameters proposed ? Milestones H.323-URL will be included in H.323v4 H.323v4 discussion/decision due by the end of August 2000 H.323-URL will be maintained and developed as a part of H.323 Annex O "Internet Technologies Complementary to H.323" Additional parameters are for consideration Registration of the URL scheme According to BCP-35 (RFC 2717) Two alternatives for registration of the "scheme name" * IETF tree * An alternate (ITU ?) tree Would like to get some guidance on which way to go here. HS: What's the practical implication on having an ITU tree ? Answer: don't know HS: Talk to Patrik Faltstrom for guidance HS: User-name or host-name missing distinction was unclear. Problem is that will mean something different than . SIP will refer to host foo, where as H.323 will refer to user foo. Of course clear within each scheme, but somewhat confusing. OL: Well, the scheme-name makes it clear what it means. Lennox: Conventional to write URL-schemes in lower-case (h323 rather than H.323). Lennox: H.323 has slew of alias addresses. Scheme wouldn't allow all of these to be represented in the URL, e.g. "call this E.164 number". OL: Discussed, but couldn't reach consensus. Lennox: Add text explaining this in draft. Lennox: How do you use it ? Send it to the GK which then goes through the whole 323 enchilada. Should describe that a little in the draft. OL: Annex O describes this. Huitema: IETF or ITU tree question: Should go for the IETF tree. RFC publish will guaranteee IETF review. URL not used only within H.323. Could very well be used in SIP e.g. to place a call to an H.323 gateway. Huitema: Can enter any kind of URL ? OL: Yes. So can easily map between SIP and H.323 URLs. (Not sure I captured this discussion correctly) OL: prefer IETF tree as well. would like IETF review as well. Will contact Patrik and ask for his input. OL: registration process is urgent JR: take what you have, resubmit with lower case, inform IESG that you would like published as Proposed Standard (not Informational), they will look a working group/people to review it. Service Routing Out of time. Will post to the list.