idnits 2.17.1 draft-ietf-ccamp-gmpls-overlay-05.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 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 539. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 546), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 47. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2004) is 7104 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) == Missing Reference: 'LSP-HIER' is mentioned on line 412, but not defined == Unused Reference: 'RFC3667' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 457, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 -- No information found for draft-ccamp-gmpls-egress-control - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Swallow 2 Internet Draft Cisco Systems, Inc 3 Category: Standards Track 4 Expiration Date: April 2005 J. Drake 5 Calient Networks, Inc 7 H. Ishimatsu 8 Japan Telecom 10 Y. Rekhter 11 Juniper Networks, Inc 13 October 2004 15 Generalize Multiprotocol Label Switching(GMPLS) 16 User-Network Interface (UNI): 17 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support 18 for the Overlay Model 20 draft-ietf-ccamp-gmpls-overlay-05.txt 22 Status of this Memo 24 By submitting this Internet-Draft, I certify that any applicable 25 patent or other IPR claims of which I am aware have been disclosed, 26 and any of which I become aware will be disclosed, in accordance with 27 RFC 3668. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright Notice 47 Copyright (C) The Internet Society (2004). All Rights Reserved. 49 Abstract 51 Generalized Multiprotocol Label Switching (GMPLS) defines both 52 routing and signaling protocols for the creation of Label Switched 53 Paths (LSPs) in various switching technologies. These protocols can 54 be used to support a number of deployment scenarios. This memo 55 addresses the application of GMPLS to the overlay model. 57 Contents 59 1 Introduction ........................................... 3 60 1.1 GMPLS User-Network Interface (GMPLS UNI) ............... 4 61 2 Addressing ............................................. 5 62 3 ERO Processing ......................................... 6 63 3.1 Path Message without ERO ............................... 6 64 3.2 Path Message with ERO .................................. 6 65 3.3 Explicit Label Control ................................. 7 66 4 RRO Processing ......................................... 7 67 5 Notification ........................................... 7 68 6 Connection Deletion .................................... 8 69 6.1 Alarm-Free Connection Deletion ......................... 8 70 6.2 Connection Deletion with PathErr ....................... 8 71 7 VPN Connections ........................................ 9 72 8 Security Considerations ................................ 9 73 9 Acknowledgments ........................................ 9 74 10 References ............................................. 10 75 10.1 Normative References ................................... 10 76 10.2 Informational References ............................... 10 77 11 Authors' Addresses ..................................... 11 78 12 Intellectual Property Notice ........................... 11 79 13 Full Copyright Statement ............................... 12 81 1. Introduction 83 Generalized Multiprotocol Label Switching (GMPLS) defines both 84 routing and signaling protocols for the creation of Label Switched 85 Paths (LSPs) in various transport technologies. These protocols can 86 be used to support a number of deployment scenarios. In a peer 87 model, edge-nodes support both a routing and a signaling protocol. 88 The protocol interactions between an edge-node and a core node are 89 the same as between two core-nodes. In the overlay model, the 90 core-nodes act more as a closed system. The edge nodes do not 91 participate in the routing protocol instance that runs among the core 92 nodes; in particular, the edge nodes are unaware of the topology of 93 the core nodes. There may, however, be a routing protocol 94 interaction between a core node and an edge node for the exchange of 95 reachability information to other edge nodes. 97 Overlay Overlay 98 Network +----------------------------------+ Network 99 +---------+ | | +---------+ 100 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 101 | | | | | | | | | | | | | | | | 102 | -+ EN +-+-----+--+ CN +----+ CN +----+ CN +---+-----+-+ EN +- | 103 | | | | +--+--| | | | | | | | | | | 104 | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | 105 | | | | | | | | | | 106 +---------+ | | | | | | +---------+ 107 | | | | | | 108 +---------+ | | | | | | +---------+ 109 | | | | +--+--+ | +--+--+ | | | 110 | +----+ | | | | | +-------+ | | | +----+ | 111 | | +-+--+ | | CN +---------------+ CN | | | | | | 112 | -+ EN +-+-----+--+ | | +---+-----+-+ EN +- | 113 | | | | | +-----+ +-----+ | | | | | 114 | +----+ | | | | +----+ | 115 | | +----------------------------------+ | | 116 +---------+ Core Network +---------+ 117 Overlay Overlay 118 Network Network 120 Legend: EN - Edge Node 121 CN - Core Node 123 Figure 1: Overlay Reference Model 125 Figure 1 shows a reference network. The core network is represented 126 by the large box in the center. It contains five core-nodes marked 127 'CN'. The four boxes around the edge marked "Overlay Network" 128 represent four islands of a single overlay network. Only 129 the nodes of this network with TE links into the core network are 130 shown. These nodes are called edge-nodes; the terminology is in 131 respect to the core network, not the overlay network. Note that each 132 box marked "Overlay Network" could contain many other nodes. Such 133 nodes are not shown; they do not participate directly in the 134 signaling described in this document. Only the edge-nodes can signal 135 to set up links across the core to other edge-nodes. 137 How a link between edge-nodes is requested and triggered is out of 138 the scope of this document, as is precisely how that link is used by 139 the Overlay Network. One posibliity is that the edge-nodes will 140 inform the other nodes of the overlay network of the existence of the 141 link possibly using a forwarding adjacency as described in 142 [MPLS-HIER]. Note that this contrasts with a forwarding adjacency 143 that is provided by the core network as a link between core nodes. 145 In the overlay model there may be restrictions on what may be 146 signaled between an edge-node and a core-node. This memo addresses 147 the application of GMPLS to the overlay model. Specifically it 148 addresses RSVP-TE procedures between an edge-node and a core-node in 149 the overlay model. All signaling procedures are identical to the 150 GMPLS extensions specified in [RFC3473] except as noted in this 151 document. 153 This document primarily addresses interactions between an edge-node 154 and it's adjacent (at the data plane) core-node - out-of-band and 155 non-adjacent signaling capablities may mean that signaling messages 156 are delivered on a longer path. Except where noted, the term 157 core-node refers to the node which is immediately adjacent to an 158 edge-node across a particular data plane interface. The term 159 core-nodes, however, refers to all nodes in the core. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 Readers are assumed to be familiar with the terminology introduced in 166 [RFC3031], [GMPLS-ARCH] and [RFC3471]. 168 1.1. GMPLS User-Network Interface (GMPLS UNI) 170 One can apply the GMPLS Overlay model at the User-Network Interface 171 (UNI) reference point defined in the Automatically Switched Optical 172 Network (ASON) [G.8080]. Consider the case where the 'Core Network' 173 in Figure 1 is a Service Provider network, and the Edge Nodes are 174 'user' devices. The interface between an EN and a CN is the UNI 175 reference point, and to support the ASON model, one must define 176 signaling across the UNI. 178 The extensions described in this memo provide mechanisms for UNI 179 signaling that are compatible with GMPLS signaling [RFC3471, 180 RFC3473]. Moreover, these mechanisms for UNI signaling are in line 181 with the RSVP model, namely, there is a single end-to-end RSVP 182 session for the user connection. The first and last hops constitute 183 the UNI, and the RSVP session carries the user parameters end-to-end. 184 This obviates the need to map (or carry) user parameters to (in) the 185 format expected by the network-to-network interface (NNI) used within 186 the Service Provider network. This in turn means that the UNI and 187 NNI can be independent of one another, which is a requirement of the 188 ASON architecture. However, in the case that the UNI and NNI are 189 both GMPLS RSVP-based, the methodology specified in this memo allows 190 for a single RSVP session to instantiate both UNI and NNI signaling, 191 if so desired, and if allowed by Service Provider policy. 193 2. Addressing 195 Addresses for edge-nodes in the overlay model are drawn from the same 196 address space as the edge-nodes use to address their adjacent 197 core-nodes. This may be the same address space as used by the 198 core-nodes to communicate among themselves or it may be a VPN space 199 supported by the core-nodes as an overlay. 201 To be more specific, an edge-node and its attached core-node must 202 share the same address space that is used by GMPLS to signal between 203 the edge-nodes across the core network. A set of tuples share the same address space if the edge-nodes in 205 the set could establish LSPs (through the core-nodes) among 206 themselves without address mapping or translation (note that 207 edge-nodes in the set may be a subset of all the edge-nodes). The 208 address space used by the core-nodes to communicate among themselves 209 may, but need not be shared with the address space used by any of the 210 tuples. 212 When multiple overlay networks are supported by a single core network 213 one or more address spaces may be used according to privacy 214 requirements. This may be achieved without varying the core-node 215 addresses since it is the tuple that 216 constitues address space membership. 218 An edge-node is identified by either a single IP address representing 219 its Node-ID, or by one or more numbered TE links that connect the 220 edge-node to the core-nodes. Core-nodes are assumed to be ignorant 221 of any other addresses associated with an edge-node (i.e. addresses 222 which are not used in signaling connections through the GMPLS core). 224 An edge-node need only know its own address, an address of the 225 adjacent core-node, and know (or be able to resolve) the address of 226 any other edge-node to which it wishes to connect, as well as (of 227 course) the addresses used in the overlay network island of which 228 it is a part. 230 A core-node need only know (and track) the addresses on interfaces 231 between that core-node and its attached edge-nodes, as well as the 232 Node IDs of those edge-nodes. In addition, a core-node needs to know 233 the interface addresses and Node IDs of other edge-nodes to which an 234 attached edge-node is permitted to connect. 236 When forming a SENDER_TEMPLATE the ingress edge-node includes either 237 its Node-ID or the address of one of its numbered TE links. In the 238 latter case the connection will only be made over this interface. 240 When forming a SESSION_OBJECT, the ingress edge-node includes either 241 the Node-ID of the egress edge-device or the address of one of the 242 egress' numbered TE links. In the latter case the connection will 243 only be made over this interface. The Extended_Tunnel_ID of the 244 SESSION Object is set to either zero or to an address of the ingress 245 edge-device. 247 Links may be either numbered or unnumbered. Further, links may be 248 bundled or unbundled. See [GMPLS-ARCH], [RFC3471], [BUNDLE], and 249 [RFC3477]. 251 3. ERO Processing 253 An edge-node MAY include an ERO. A core-node MAY reject a Path 254 message that contains an ERO. Such behavior is controlled by 255 (hopefully consistent) configuration. If a core-node rejects a Path 256 message due to the presence of an ERO it SHOULD return an PathErr 257 message with an error code of "Unknown object class" toward the 258 sender as described in [RFC3209]. This causes the path setup to fail. 260 Further a core-node MAY accept EROs which only include the ingress 261 edge-node, the ingress core-node, the egress core-node and the egress 262 edge-node. This is to support explicit label control on the 263 edge-node interface, see below. If a core-node rejects a Path 264 message due to the presence of an ERO not of the permitted format it 265 SHOULD return an PathErr message with an error code of Bad Explicit 266 Route Object as defined in [RFC3209]. 268 3.1. Path Message without ERO 270 When a core-node receives a Path message from an edge-node that 271 contains no ERO, it MUST calculate a route to the destination and 272 include that route in a ERO, before forwarding the PATH message. One 273 exception would be if the egress edge-node were also adjacent to this 274 core-node. If no route can be found, the core-node SHOULD return a 275 PathErr message with an error code and value of 24,5 - "No route 276 available toward destination". 278 3.2. Path Message with ERO 280 When a core-node receives a Path message from an edge-node that 281 contains an ERO, it SHOULD verify the route against its topology 282 database before forwarding the PATH message. If the route is not 283 viable (according to topology, currently available resources, or 284 local policy), then a PathErr message with an error code and value of 285 24,5 - "No route available toward destination" should be returned. 287 3.3. Explicit Label Control 289 In order to support explicit label control and full identification of 290 the egress link an ingress edge-node may include this information in 291 the ERO that it passes to its neighboring core-node. In the case that 292 no other ERO is supplied, this explicit control information is 293 provided as the only hop of the ERO and is encoded by setting the 294 first subobject of the ERO to the node-ID of the egress core-node 295 with the L-bit set; following this subobject are all other subobjects 296 necessary to identify the link and labels as they would normally 297 appear. 299 The same rules apply to the presence of the explicit control 300 subobjects as the last hop in the ERO if a fuller ERO is supplied by 301 the ingress edge-node to its neighbor core-node, but in this case the 302 L-bit MAY be clear. 304 This process is described in [RFC3473] and [EXPLICIT]. 306 4. RRO Processing 308 An edge-node MAY include an RRO. A core-node MAY remove the RRO from 309 the Path message before forwarding it. Further the core-node may 310 remove the RRO from a Resv message before forwarding it to the 311 edge-node. Such behavior is controlled by (hopefully consistent) 312 configuration. 314 Further a core-node MAY edit the RRO in a Resv message such that it 315 includes only the subobjects from the egress core-node through the 316 egress edge-node. This is to allow the ingress node to be aware of 317 the selected link and labels on at the far end of the connection. 319 5. Notification 321 An edge-node MAY include a NOTIFY_REQUEST object in both the Path and 322 Resv messages it generates. Core-nodes may send Notify 323 messages to edge-nodes which have included the NOTIFY_REQUEST object. 325 A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv 326 message received from an edge-node before forwarding it. 328 If no NOTIFY_REQUEST object is present in the Path or Resv received 329 from an edge-node, the core-node adjacent to the edge-node may 330 include a NOTIFY_REQUEST object and set its value to its own address. 332 In either of the above cases, the core-node SHOULD NOT send Notify 333 messages to the edge-node. 335 When a core-node receives a NOTIFY_REQUEST object from an edge-node, 336 it MAY update the Notify Node Address with its own address before 337 forwarding it. In this case, when Notify messages are received, they 338 MAY be selectively (based on local policy) forwarded to the 339 edge-node. 341 6. Connection Deletion 343 6.1. Alarm-Free Connection Deletion 345 RSVP-TE currently deletes connections using either a single pass 346 PathTear message, or a ResvTear and PathTear message combination. 347 Upon receipt of the PathTear message, a node deletes the connection 348 state and forwards the message. In optical networks, however, it is 349 possible that the deletion of a connection (e.g., removal of the 350 cross-connect) in a node may cause the connection to be perceived as 351 failed in downstream nodes (e.g., loss of frame, loss of light, 352 etc.). This may in turn lead to management alarms and perhaps the 353 triggering of restoration/protection for the connection. 355 To address this issue, the graceful connection deletion procedure 356 SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST 357 be sent in Path or Resv message along the connection's path to inform 358 all nodes enroute of the intended deletion, prior to the actual 359 deletion of the connection. The procedure is described in [RFC3473]. 361 An ingress core-node receiving a PathTear without having first seen 362 an ADMIN_STATUS object informing it that the connection is about to 363 be deleted MAY pause the PathTear and first send a Path message with 364 an ADMIN_STATUS object to inform all downstream LSRs that the 365 connection is about to be deleted. When the Resv is received echoing 366 the ADMIN_STATUS or using a timer as described in [RFC3473], the 367 ingress core-node MUST forward the PathTear. 369 6.2. Connection Deletion with PathErr 371 [RFC3473] introduces the Path_State_Removed flag to a PathErr message 372 to indicate that the sender has removed all state associated with the 373 LSP and does not need to see a PathTear. A core-node next to an 374 edge-node MAY map between teardown using ResvTear/PathTear and 375 PathErr with Path_state_Removed. 377 A core-node next to an edge-node receiving a ResvTear from its 378 downstream neighbor MAY respond with a PathTear and send a PathErr 379 with Path_State_Removed further upstream. 381 Note, however, that a core-node next to an edge-node receiving a 382 PathErr with Path_State_Removed from its downstream neighbor MUST NOT 383 retain Path state and send a ResvTear further upstream since that 384 would imply that Path state further downstream had also been 385 retained. 387 7. VPN Connections 389 As stated in the addressing section above, the extensions in this 390 document are designed to be compatible with the support of VPNs. 391 Since the core network may be some technology other than GMPLS, no 392 mandatory means of mapping core connections to access connections is 393 specified. However, when GMPLS is used for the core network, it is 394 RECOMMENDED that the following procedure based on [LSP-HIER] is 395 followed. 397 The VPN connection is modeled as being three hops. One for each 398 access link and one hop across the core network. 400 The VPN connection is established using a two step procedure. When a 401 Path message is received at a core node on an interface which is part 402 of a VPN, the Path message is held until a core connection is 403 established. 405 The connection across the core is setup as a separate signaling 406 exchange between the core nodes, using the address space of the core 407 nodes. While this exchange is in progress, the original Path message 408 is held at the ingress core node. Once the exchange for the core 409 connection is complete, this connection is used in the VPN connection 410 as if it were a single link. This is signaled by including an IF_ID 411 RSVP_HOP object (defined in [RFC3473]) using the procedures defined 412 in [LSP-HIER]. 414 The original Path message is then forwarded within the VPN addressing 415 realm to the core node attached to the destination edge node. Many 416 ways of accomplishing this are available, including IP and GRE 417 tunnels and BGP/MPLS VPNs. Specifying a particular means is beyond 418 the scope of this document. 420 8. Security Considerations 422 This draft imposes no new security risks over [RFC3473]. In fact it 423 represents a lower trust model between the core and edge-nodes as the 424 core is permitted to hide its topology from the edge-nodes. The core 425 is also permitted to restrict the actions of edge-nodes by filtering 426 out specific RSVP objects. 428 9. Acknowledgments 430 The authors would like to thank Kireeti Kompella, Jonathan Lang, 431 Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and 432 Adrian Farrel for their comments and input. Thanks for thorough final 433 reviews from Loa Andersson and Dimitri Papadimitriou. 435 Adrian Farrel edited the last two revisions of this document to 436 incorporate comments from Working Group last call and from AD review. 438 10. References 440 10.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels," RFC 2119. 445 [RFC3471] Berger, L., "Generalized MPLS Signaling Functional 446 Description", RFC 3471, January 2003. 448 [RFC3473] Berger, L., "Generalized MPLS Signaling RSVP-TE 449 Extensions", RFC 3473, January 2003. 451 [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for 452 LSP Tunnels", RFC 3209, December 2001. 454 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 455 RFC 3667, February 2004. 457 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 458 Technology", BCP 79, RFC 3668, February 2004. 460 10.2. Informational References 462 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 463 Label Switching Architecture", RFC 3031, January 2001. 465 [RFC3477] Kompella, K., and Rekhter, Y., "Signaling Unnumbered 466 Links in RSVP-TE", RFC 3477, January 2003. 468 [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 469 Bundling in MPLS Traffic Engineering", 470 draft-ietf-mpls-bundle-04.txt, July 2002, work in 471 progress. 473 [EXPLICIT] Berger, L., "GMPLS Signaling Procedure For Egress 474 Control", draft-ccamp-gmpls-egress-control-02.txt, 475 May 2004, work in progress. 477 [GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol 478 Label Switching (GMPLS) Architecture", 479 draft-ietf-ccamp-gmpls-architecture-07.txt, May 2003, 480 work in progress. 482 [MPLS-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 483 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, 484 September 2001, work in progress. 486 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 487 Automatically Switched Optical Network (ASON)," 488 November 2001 (and Revision, January 2003). 489 For information on the availability of this document, 490 please see http://www.itu.int. 492 11. Authors' Addresses 494 John Drake 495 Calient Networks 496 5853 Rue Ferrari 497 San Jose, CA 95138 498 Phone: +1 408 972 3720 499 Email: jdrake@calient.net 501 Hirokazu Ishimatsu 502 Japan Telecom Co., Ltd. 503 2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan 504 Tel: +81 3 5540 8493 505 Email: hirokazu.ishimatsu@japan-telecom.co.jp 507 Yakov Rekhter 508 Juniper Networks, Inc. 509 Email: yakov@juniper.net 510 George Swallow 511 Cisco Systems, Inc. 512 1414 Massachusetts Ave, 513 Boxborough, MA 01719 514 Phone: +1 978 936 1398 515 Email: swallow@cisco.com 517 12. Intellectual Property Notice 519 The IETF takes no position regarding the validity or scope of any 520 Intellectual Property Rights or other rights that might be claimed 521 to pertain to the implementation or use of the technology 522 described in this document or the extent to which any license 523 under such rights might or might not be available; nor does it 524 represent that it has made any independent effort to identify any 525 such rights. Information on the procedures with respect to rights 526 in RFC documents can be found in BCP 78 and BCP 79. 528 Copies of IPR disclosures made to the IETF Secretariat and any 529 assurances of licenses to be made available, or the result of an 530 attempt made to obtain a general license or permission for the use 531 of such proprietary rights by implementers or users of this 532 specification can be obtained from the IETF on-line IPR repository 533 at http://www.ietf.org/ipr. 535 The IETF invites any interested party to bring to its attention 536 any copyrights, patents or patent applications, or other 537 proprietary rights that may cover technology that may be required 538 to implement this standard. Please address the information to the 539 IETF at ietf-ipr@ietf.org. 541 13. Full Copyright Statement 543 Copyright (C) The Internet Society (2004). This document is 544 subject to the rights, licenses and restrictions contained in BCP 545 78, and except as set forth therein, the authors retain all their 546 rights. 548 This document and the information contained herein are provided 549 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 550 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 551 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 552 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 553 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 554 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 555 PARTICULAR PURPOSE.