idnits 2.17.1 draft-ietf-iptel-trunk-group-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 566), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To the processing User Agent Server (UAS), a trunk group in the R-URI implies that it should use the named trunk group for the outbound call. If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD not use any other trunk group other than the one requested. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2005) is 7011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) == Outdated reference: A later version (-09) exists of draft-ietf-iptel-tgrep-04 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL WG V. Gurbani 3 Internet-Draft Lucent Technologies 4 Expires: August 15, 2005 C. Jennings 5 Cisco Systems 6 February 14, 2005 8 Representing trunk groups in tel/sip Uniform Resource Identifiers 9 (URIs) 10 draft-ietf-iptel-trunk-group-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 15, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This document describes a standardized mechanism to convey trunk 44 group- related information in sip and tel Uniform Resource 45 Identifiers (URIs). An extension to the "tel" URI is defined for 46 this purpose. 48 This work is being discussed on the iptel@ietf.org mailing list. 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Requirements and rationale . . . . . . . . . . . . . . . . . . 4 56 4.1 sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 4 57 4.2 Trunk group namespace: global or local? . . . . . . . . . 5 58 4.3 Originating trunk group and terminating trunk group . . . 5 59 4.4 Intermediary processing of trunk groups . . . . . . . . . 6 60 5. Reference architecture . . . . . . . . . . . . . . . . . . . . 7 61 6. Trunk group identifier: ABNF and examples . . . . . . . . . . 7 62 7. Example call flows . . . . . . . . . . . . . . . . . . . . . . 8 63 7.1 Trunk group in a Contact header . . . . . . . . . . . . . 8 64 7.2 Trunk group in the R-URI . . . . . . . . . . . . . . . . . 9 65 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 66 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 70 11.2 Informative References . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . . . 13 74 1. Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC-2119 [1]. 80 2. Definitions 82 Call routing in the Public Switched Telephone Network (PSTN) is 83 accomplished by routing calls over specific circuits (commonly 84 referred to as "trunks") between Time Division Multiplexed (TDM) 85 circuit switches. In large switches, a group of trunks that connects 86 to the same target switch or network is called a "trunk group." 87 Consequently, trunk groups have labels, which are used as the main 88 indication for the previous and next TDM switch participating in 89 routing the call. 91 Formally, we define a trunk and trunk group and related terminology 92 as follows (definition of "trunk" and "trunk group" is from [5]). 94 Trunk: In a network, a communication path connecting two switching 95 systems used in the establishment of an end-to-end connection. In 96 selected applications, it may have both its terminations in the 97 same switching system. 99 Trunk Group: A set of trunks, traffic engineered as a unit, for 100 the establishment of connections within or between switching 101 systems in which all of the paths are interchangeable. 103 Digital Signal 0 (DS0): Digital Signal X is a term for a series of 104 standard digital transmission rates based on DS0, a transmission 105 rate of 64kbps (the bandwidth normally used for one telephone 106 voice channel). The European E-carrier system of transmission 107 also operates using the DS series as a base multiple. 109 Since the introduction of ubiquitous digital trunking, which resulted 110 in the allocation of DS0s between end offices in minimum groups of 24 111 (in North America), it has become common to refer to bundles of DS0s 112 as a trunk. Strictly speaking, however, a trunk is a single DS0 113 between two PSTN end offices - however, for the purposes of this 114 document, the PSTN interface of a gateway acts effectively as an end 115 office (i.e. if the gateway interfaces with Signaling System 7 116 (SS7), it has its own SS7 point code, and so on). A trunk group, 117 then, is a bundle of DS0s (that need not be numerically contiguous in 118 an SS7 Trunk Circuit Identification Code numbering scheme) which are 119 grouped under a common administrative policy for routing. 121 A Session Initiation Protocol (SIP) [3] to PSTN gateway may have 122 trunks that are connected to different carriers. It is entirely 123 reasonable for a SIP proxy to choose -- based on factors not 124 enumerated in this document -- which carrier a call is sent to when 125 it proxies a session setup request to the gateway. Since multiple 126 carriers can terminate a particular PSTN phone number, the phone 127 number itself is not sufficient enough to identify the carrier at the 128 gateway. An additional piece of information in the form of a trunk 129 group can be used to further pare down the choices at the gateway. 130 How the proxy picked a particular trunk group is outside the scope of 131 this document ([6] provides one such way); once the trunk group has 132 been decided upon, this document provides a standardized means to 133 represent it. 135 3. Problem statement 137 Currently, there isn't any standardized manner of transporting 138 trunk-groups between Internet signaling entities. This leads to 139 ambiguity on at least two fronts: 141 1. Positional ambiguity: A SIP proxy that wants to send a call to an 142 egress VoIP gateway may insert the trunk-group as a parameter in 143 the user portion of the Request-URI (R-URI), or it may insert it 144 as a parameter to the R-URI itself. This ambiguity persists in 145 the reverse direction as well, that is, when an ingress VoIP 146 gateway wants to send a incoming call notification to its default 147 outbound proxy. 148 2. Semantic ambiguity: The lack of any standardized grammar to 149 represent trunk groups leads to the unfortunate choice of ad hoc 150 names and values. 152 VoIP routing entities in the Internet, such as SIP proxies, may be 153 interested in using trunk-group information for normal operations. 154 To that extent, any standards-driven requirements will enable proxies 155 from one vendor to interoperate with gateways from yet another 156 vendor. Absent such guidelines, inter-operability will suffer as a 157 proxy vendor must conform to the expectations of a gateway as to 158 where it expects trunk-group information to be present (and vice 159 versa). 161 The aim of this Internet draft is to outline how to structure and 162 represent the trunk group information as an extension to the tel URI 163 [4] in a standardized manner. 165 4. Requirements and rationale 167 4.1 sip URI or tel URI? 169 REQ 1: Trunk group information MUST be defined as an extension to the 170 "tel" URI [4]. 172 The trunk group information can be carried in either the "sip" URI or 173 the "tel" URI. Since trunks groups are intimately associated with 174 the PSTN, it seems reasonable to define them as extensions to the 175 "tel" URI (any SIP request that goes to a gateway could reasonably be 176 expected to have a tel URL, in whole or in part, in its R-URI 177 anyway). Furthermore, using the tel URL also allows this format to 178 be reused by non-SIP VoIP protocols (which could include anything 179 from MGCP or Megaco to H.323, if the proper information elements are 180 created). 182 Finally, once the trunk-group is defined for a "tel" URI, the 183 normative procedures of Section 19.1.6 of [3] can be used to derive 184 an equivalent "sip" URI from a "tel" URI, complete with the trunk 185 group information. 187 4.2 Trunk group namespace: global or local? 189 REQ 2: Inter-domain trunk group name collisions MUST be prevented. 191 Under normal operations, trunk groups are pertinent only within an 192 administrative domain (i.e. local scope). However, given that 193 inadvertent cross-domain trunk group name collisions may occur, it is 194 desirable to to prevent these. The judicious use of namespaces is a 195 solution to this problem. The use of the "phone-context" parameter 196 of the tel URI appears to provide a satisfactory manner of imposing a 197 namespace on trunk group names by specifying a global number or any 198 number of its leading digits (e.g., +33) or a domain name (see 199 Section 5.1.5 of [4]) . 201 The use of the "phone-context" parameter in conjunction with this 202 draft is REQUIRED; implementations choosing to include trunk groups 203 information MUST be capable of parsing and generating the 204 "phone-context" parameter of the tel URI. If a receiver of a SIP 205 request is not the owner of the domain specified in the 206 "phone-context", it MUST treat the trunk group as if it was not 207 there. 209 4.3 Originating trunk group and terminating trunk group 211 REQ 3: Originating trunk group and destination trunk group SHOULD be 212 able to appear separately and concurrently in a SIP message. 214 SIP routing entities can make informed routing decisions based on 215 either the originating or the terminating trunk groups. Thus a 216 requirement that both of these trunk groups need to be carried in SIP 217 requests. 219 Instead of having two parameters, one for the originating trunk group 220 and the other for a terminating trunk group, the placement of the 221 trunk group parameter in a SIP Contact header or the R-URI, 222 respectively, signifies the intent. A proxy (or any other 223 intermediary -- see next section) MAY insert a trunk group appears in 224 the R-URI; to the next downstream entity this signifies an egress (or 225 terminating) trunk group to be used. 227 Conversely, when a trunk group parameter appears in the Contact 228 header, this signifies the trunk group over which the call came over, 229 i.e., the ingress (or orgininating) trunk group. 231 4.4 Intermediary processing of trunk groups 233 REQ 4: SIP network intermediaries (proxy server and redirect servers) 234 should be able to add the destination trunk group attribute to SIP 235 sessions as a route is selected for a call. 237 If the trunk group parameter appears in a R-URI of a request, it 238 represents the destination trunk group. 240 This is consistent with using the R-URI as a routing element; SIP 241 routing entities may use the trunk group parameter in the R-URI to 242 make intelligent routing decisions. Furthermore, this also 243 satisfies REQ 4, since a SIP network intermediary can modify the 244 R-URI to include the trunk group information. 246 To the processing User Agent Server (UAS), a trunk group in the R-URI 247 implies that it should use the named trunk group for the outbound 248 call. If a UAS supports trunk groups but is not configured with the 249 particular trunk group identified in the R-URI, it SHOULD not use any 250 other trunk group other than the one requested. 252 A User Agent Client (UAC) that initiates a call and supports this 253 draft MAY include the trunk group in the Contact header. If it does 254 so, the trunk group in the Contact header represents the originating 255 trunk group. Subsequent requests destined to that UAC MUST copy the 256 trunk group from the Contact header into the R-URI. Note that a 257 Contact URI MUST be a sip or sips URI, thus, what appears in the 258 Contact header is a SIP translation of the tel URI, complete with the 259 trunk group information. 261 Arguably, the originating trunk group can be part of the From URI. 262 However, semantically, the URI in a From header is an abstract 263 identifier which represents the resource thus identified on a 264 long-term basis. The presence of a trunk group, on the other 265 hand, signifies a binding that is valid for the duration of the 266 session only; a trunk group has no significance once the session 267 is over. Thus, the Contact URI is the best place to impart this 268 information since it has exactly those semantics. 270 5. Reference architecture 272 Consider Figure 1, which depicts a SIP proxy in a routing 273 relationship with three gateways in its domain, GW1, GW2, and GW3. 274 Among other sources of request arrival (not shown in Figure) at the 275 proxy is GW1. Gateways GW2 and GW3 are used as egress gateways from 276 the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. 277 GW3 has only one trunk group configured (TG3-1). 279 +-----+ TG2-1 280 | |--------> To 281 TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN 282 From ----->| | | SIP | | | |--------> 283 PSTN | GW1 |--->| Proxy |-----+ +-----+ 284 ----->| | +-------+ | +-----+ TG3-1 285 +-----+ | | |--------> To 286 +---->| GW3 | PSTN 287 | |--------> 288 +-----+ 289 Figure 1: Reference architecture 291 GW1 in Figure 1 is always cognizant of any requests that arrive over 292 trunk group TG1-1. If it wishes to propagate the ingress trunk group 293 to the proxy, it MUST arrange for the trunk group to appear in the 294 Contact header of the SIP request destined to the proxy. The proxy 295 will, in turn, propagate the ingress trunk group in the Contact 296 header further downstream. 298 The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is 299 assumed that the proxy has access to a routing table for GW2 and GW3 300 which includes the appropriate trunk groups to use when sending a 301 call to the PSTN (exactly how this table is constructed is out of 302 scope for this draft; [6] is one way to do so, a manually created and 303 maintained routing table is another). When the proxy sends a request 304 to either of the egress gateways, and the gateway routing table is so 305 configured that a trunk group is required by the gateway, the proxy 306 MUST arrange for the trunk group to appear in the SIP R-URI of the 307 request destined to that gateway. 309 6. Trunk group identifier: ABNF and examples 311 The Augmented Backus Naur Form [2] syntax for a trunk group 312 identifier is given below and extends the "par" production rule of 313 the tel URI defined in [4]: 315 par = parameter / extension / isdn-subaddress / trunk-group 317 trunk-group = ";tgrp=" trunk-group-label 318 trunk-group-label = *1( unreserved / escaped / 319 trunk-group-unreserved ) 320 trunk-group-unreserved = "/" / "&" / "+" / "$" 322 trunk-group-unreserved is the intersection of param-unreserved 323 defined in [4] and user-unreserved defined in [3]. Since the 324 trunk group is an extension to the tel URI and will end up as the 325 user portion of a SIP URI, the ABNF for it has to ensure that it 326 can be adequately represented in both the constructs. 328 Examples: 330 tel:+15555551212;phone-context=telco.example.com;tgrp=tg55 331 tel:0216;phone-context=+1-555-555;tgrp=TG-1 333 The example URIs above extends the tel URI with a trunk group 334 identifier. Transforming these "tel" URI to "sip" URIs yields, 335 respectively: 337 sip:+15555551212;phone-context=telco.example.com;tgrp=tg55@ 338 isp.example.net 339 sip:0216;phone-context=+1-555-555;tgrp=TG-1@isp.example.net 341 7. Example call flows 343 7.1 Trunk group in a Contact header 345 This call flow depicts a gateway accepting a call from the PSTN and 346 conversing with its SIP proxy in order to further route the call 347 (F1). At some later time after the call has been established, the 348 gateway receives a BYE (F2) to tear down the call (note the R-URI in 349 the BYE). 351 PSTN Ingress Proxy 352 Gateway 353 | | | 354 |Call Request | | 355 +------------->| | 356 | +---F1----->| 357 ... ... ... 359 | | 360 | |<----F2--- 362 F1: 363 INVITE sip:40216@isp.example.net SIP/2.0 364 ... 365 Contact: 367 ... 369 F2: 370 BYE sip:40216;phone-context=isp.example.net;tgrp=tg55@ 371 igwy.isp.example.net SIP/2.0 372 ... 374 It is worth documenting the behavior when an incoming call from the 375 PSTN is received at a gateway without a calling party number. 376 Consider Figure 1; in it, GW1 gets a call request from the PSTN 377 without a calling party number. This is not an uncommon case, and 378 may happen for a variety of reasons, including privacy and 379 interworking between different signaling protocols before the request 380 reached GW1. Under normal circumstances (i.e., instances where the 381 calling party number is present in signaling), GW1 would derive a sip 382 URI to insert into the Contact header. This sip URI may contain, as 383 its user portion, the calling party number from from the incoming SS7 384 signaling information. The trunk group information then becomes part 385 of the user portion as discussed previously. 387 If a gateway receives an incoming call where the calling party number 388 is not available, it MUST create a sip URI that has, as its user 389 portion, a token that is generated locally and has local significance 390 to the gateway. Details of generating such a token are 391 implementation dependent; potential candidates include the gateway 392 line number or port number where the call was accepted. This sip URI 393 is subsequently inserted in the Contact header of the SIP request 394 going downstream from the gateway. 396 The tel scheme does not allow for an empty URI; thus the 397 global-number or local-number production rule of the tel URI [4] 398 cannot contain an empty string. Consequently, the behavior in the 399 above paragraph is mandated for cases where the incoming SS7 400 signaling message does not contain a calling party number. 402 7.2 Trunk group in the R-URI 404 This call flow depicts a proxy sending a request to a gateway with a 405 particular trunk group (F1). The gateway sends the request to the 406 PSTN; when the callee picks up the phone, a 200 OK is generated 407 towards the UAC (F2). Note the Contact of the 200 OK; it contains 408 the trunk group information. Subsequent requests from the UAC will 409 contain this URI as the R-URI. 411 UAC Proxy Egress 412 Gateway 413 | | | 414 |Call Request | | 415 +------------->| | 416 | +---F1------>| 417 | | |---> Interface with PSTN and 418 | | | received Answer Complete 419 | | | Message (ACM) 420 | +<-------F2--+ 421 | | | 422 ... ... ... 424 F1: 425 INVITE sip:+15555551212;phone-context=isp.example.net;tgrp=TG2-1@ 426 egwy.isp.example.net SIP/2.0 427 ... 428 F2: 429 SIP/2.0 200 OK 430 ... 431 Contact: 434 8. Security considerations 436 The extension defined in this document does not add any additional 437 security concerns beyond those already enumerated in [3]. The trunk 438 group information is carried in R-URIs and Contact headers; it is 439 simply a modifier of an address, and the trust imparted to that 440 address is not affected by such a modifier. The privacy information 441 revealed with trunk groups does not generally advertise much 442 information about a particular (human) user. It does, however, 443 convey two pieces of potentially private information which may be 444 considered sensitive by carriers. First, it may reveal how a carrier 445 may be performing least-cost routing and peering; and secondly, it 446 does introduce an additional means for network topology and 447 information of a carrier. It is up to the discretionary judgment of 448 the carrier if it wants to include the trunk group information and 449 reveal potentially sensitive information on its network topology. 451 9. IANA considerations 453 Section 9 of [4] creates a registry for tel URI parameters. This 454 document updates the registry with the following entry: 456 Parameter name: tgrp 458 Description: A trunk group on which an incoming call was received 459 at an ingress gateway or a trunk group on which an outgoing call 460 should be placed at an egress gateway. 462 This parameter is not mandatory. 464 Syntax restrictions: Details on the syntax are explained in RFC 465 AAAA. A phone-context parameter must occur in any tel URL that 466 contains a tgrp parameter. 468 Reference: RFC AAAA 469 [Note to RFC editor: Please replace AAAA with the RFC number 470 assigned to this document.] 472 10. Acknowledgments 474 The authors would like to acknowledge the efforts of the participants 475 of the SIPPING and IPTEL working group, especially Bryan Byerly, John 476 Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike 477 Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, 478 Takuya Sawada, Tom Taylor, and Al Varney. 480 11. References 482 11.1 Normative References 484 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 485 Levels", BCP 14, RFC 2119, March 1997. 487 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 488 Specifications: ABNF", RFC 2234, November 1997. 490 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 491 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 492 Session Initiation Protocol", RFC 3261, June 2002. 494 [4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, 495 December 2004. 497 11.2 Informative References 499 [5] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, 500 . 502 [6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H. and D. Shah, 503 "A Telephony Gateway REgistration Protocol (TGREP)", 504 draft-ietf-iptel-tgrep-04.txt (work in progress), October 2004. 506 Authors' Addresses 508 Vijay Gurbani 509 Lucent Technologies 510 2000 Lucent Lane 511 Rm 6G-440 512 Naperville, IL 60566 513 USA 515 Phone: +1 630 224 0216 516 EMail: vkg@lucent.com 518 Cullen Jennings 519 Cisco Systems 520 170 West Tasman Drive 521 Mailstop SJC-21/3 522 San Jose, CA 95134 523 USA 525 Phone: +1 408 421 9990 526 EMail: fluffy@cisco.com 528 Intellectual Property Statement 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed to 532 pertain to the implementation or use of the technology described in 533 this document or the extent to which any license under such rights 534 might or might not be available; nor does it represent that it has 535 made any independent effort to identify any such rights. Information 536 on the procedures with respect to rights in RFC documents can be 537 found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use of 542 such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository at 544 http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org. 552 Disclaimer of Validity 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 557 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 558 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 559 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Copyright Statement 564 Copyright (C) The Internet Society (2005). This document is subject 565 to the rights, licenses and restrictions contained in BCP 78, and 566 except as set forth therein, the authors retain all their rights. 568 Acknowledgment 570 Funding for the RFC Editor function is currently provided by the 571 Internet Society.