Network Working Group R. Aggarwal Internet Draft Juniper Networks Expiration Date: April 2006 October 2005 Signaling Tunnel Identifiers and Capabilities in BGP draft-raggarwa-l3vpn-tunnel-attribute-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes a mechanism that allows a router to signal the identifiers of IP/MPLS Tunnels, for which it is the headend, using Border Gateway Protocol (BGP). One application of this mechanism is multicast in BGP - Multi-Protocol-Label Switching (MPLS) Virtual Private Networks (VPNs). This document also proposes a mechanism that allows a router to signal its tunnel enapsulation/decapsulation capabilities using BGP. One application of this is signaling MPLS upstream label assignment capability when BGP is used to advertise MPLS upstream assigned labels. Raggarwa [Page 1] Internet Draftdraft-raggarwa-l3vpn-tunnel-attribute-00.txt October 2005 Table of Contents 1 Specification of requirements ......................... 2 2 Introduction .......................................... 2 3 BGP Tunnel Identifier Attribute ....................... 3 4 BGP Tunnel Capabilities Extended Community ............ 3 5 IANA Considerations ................................... 4 6 Security Considerations ............................... 4 7 Acknowledgements ...................................... 4 8 References ............................................ 5 8.1 Normative References .................................. 5 8.2 Informative References ................................ 5 9 Author Information .................................... 5 10 Intellectual Property Statement ....................... 6 11 Full Copyright Statement .............................. 6 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction This document proposes a mechanism that allows a router to signal the identifiers of IP/MPLS Tunnels, for which it is the headend, using Border Gateway Protocol (BGP). This information is signaled using a new BGP attribute [BGP]. One application of this mechanism is multi- cast in BGP - Multi-Protocol-Label Switching (MPLS) Virtual Private Networks (VPNs) [MVPN]. This document also proposes a mechanism that allows a router to sig- nal its tunnel enapsulation/decapsulation capabilities using BGP. These capabilities are signaled using a new BGP extended community [BGP-EXT-COM]. One application of this is signaling MPLS upstream label assignment capability when BGP is used to advertise MPLS upstream assigned labels [MPLS-UPSTREAM]. Raggarwa [Page 2] Internet Draftdraft-raggarwa-l3vpn-tunnel-attribute-00.txt October 2005 3. BGP Tunnel Identifier Attribute A router advertises its tunnel identifiers in BGP using a new optional Tunnel Attribute. This attribute is transitive across Autonoumous System Boundary with type code to be assigned by IANA. This attribute can be attached to a NLRI advertisement. For example this new attribute may be attached to a BGP-MVPN NLRI advertisment [BGP-MVPN]. The tunnel identifier is interpreted in the context of the NLRI that it is attached to. For example if the NLRI advertises a MVPN, that the advertising PE is a member of, the attribute signals the tunnel identifier of the tunnel used by the advertising PE to send data traffic for the MVPN [MVPN]. The value field of the attribute contains a Tunnel Identifier with the following format: +---------------------------------+ | Tunnel Type (2 octets) | +---------------------------------+ | Tunnel Identifier (variable) | +---------------------------------+ The tunnel type identifies the type of the tunneling technology used to establish the tunnel. The type determines the syntax and semantics of the tunnel identifier field. The tunnel types and identifiers are to be defined in appliaction specific documents. 4. BGP Tunnel Capabilities Extended Community We define a BGP opaque extended community that can be attached to a BGP NLRI advertisement to indicate the MPLS or other encapsulation capabilities of such a NLRI. It is referred to as the Tunnel Encapsu- lation Capabilities extended community. It is transitive across the Autonomous System boundary. For example this new extended community may be attached to a BGP-MVPN NLRI advertisment [BGP-MVPN] to indi- cate that the originating PE supports MPLS upstream label assignment [MPLS-UPSTREAM]. The Tunnel Encapsulation Capabilities community is of an extended type. The value of the high-order octet of the Type Field is 0x43. The value of the low-order octet of the Type field of this extended community is to be assigned by IANA [BGP-EXT-COM]. The Tunnel encapsulation extended community has the following format: Raggarwa [Page 3] Internet Draftdraft-raggarwa-l3vpn-tunnel-attribute-00.txt October 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x43 |Sub-Type = TBD | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Encapsulation Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encapsulation capabilities bit-mask indicates all the encapsula- tions supported by the BGP speaker for the advertised NLRI. The usage of these capabilities is to be defined in application specific documents. The following encapsulation capabilities are defined as of now: 0x00000001 MPLS Upstream Label Capability 0x00000002 Multicast Shared Root 5. IANA Considerations This document defines a new BGP Tunnel Attribute and the type code of this attribute is to be assigned by IANA. This document also defines a BGP Tunnel Encapsulation Capabilities extended community and the sub-type of this extended community is to be assigned by IANA. The tunnel types in the Tunnel Attribute are to be assigned by IETF con- sensus and IANA is to maintain a registry for these tunnel types. The encapsulation capabilities in the tunnel encapsulation extended com- munity are to be assigned by IETF consensus as well and IANA is to maintain a registry for these capabilities. IANA is requested to assign the bits 0x00000001 - 0x00000002 in this registry, as defined in section 4. 6. Security Considerations This document does not introduce any new security issues. The secu- rity issues identified in [BGP-EXT-COM], [BGP] are still relevant. 7. Acknowledgements This document has evolved over a period of time and several individu- als have contributed to the ideas that have been distilled in this document. Thanks to Robert Raszuk for his contribution. Thanks to the authors of [PPVPN-SIG] for their contribution. We would also like to thank Enke Chen, Jenny Yuan, Naiming Shen, Acee Lindem,and Ravi Chan- dra for their cntribution. Raggarwa [Page 4] Internet Draftdraft-raggarwa-l3vpn-tunnel-attribute-00.txt October 2005 Thanks to Yakov Rekhter for his comments and suggestions. 8. References 8.1. Normative References [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- els.", Bradner, March 1997 [BGP] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [BGP-EXT-COM] S.R. Sangli et. al., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-09.txt. 8.2. Informative References [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs" draft-ietf-l3vpn-2547-mcast-00.txt [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa- mpls-upstream-label-01.txt [BGP-MVPN] R. Aggarwal, C. Kodeboniya, Y. Rekhter, E. Rosen, "BGP Encodings for Multicast in BGP/MPLS VPNs", draft-raggarwa- l3vpn-2547-mcast-bgp-00.txt [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, draft-rosen-mpls-codepoint-01.txt [PPVPN-SIG] R. Aggarwal, R. Raszuk, F. L. Faucheur, C. Geoffrey, J. D. Clercq, "Signaling Tunnel Encapsulation/Decapsulation Capabili- ties", draft-raggarwa-ppvpn-tunnel-encap-01.txt 9. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Raggarwa [Page 5] Internet Draftdraft-raggarwa-l3vpn-tunnel-attribute-00.txt October 2005 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 11. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Raggarwa [Page 6]