Network Working Group Chaitanya Kodeboyina Internet Draft Juniper Networks Expiration Date: May 2005 Chris Metz Cisco Systems Peter Busschbach Lucent Technologies Carrying ATM reachability information in BGP draft-ck-bgp-atm-nlri-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 defines multi-protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Asynchronous Transer Mode (ATM) network reachability information. This information exchange is one component in a solution to connect ATM network islands over an MPLS core. draft-ck-bgp-atm-nlri-01.txt [Page 1] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 Conventions used in this document 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 RFC-2119 [KEYWORDS]. 1. Introduction Service providers want to converge all their legacy network services over a common MPLS core. In particular, there is a lot of interest in migrating Asynchronous Transfer Mode (ATM) network services to an MPLS core. But at the same time, service providers would like to preserve their investment in existing ATM networks. Ideally, they would like to connect ATM network islands over an MPLS core and provide ATM network services over these interconnected networks. Switched ATM connectivity operating across the MPLS network requires that the switches in the source ATM network have knowledge of the ATM addresses (prefixes) of the switches in the destination ATM network. This could be handled by configuring static routes on some or all of the ATM switches but clearly this imposes a significant provisioning burden and is not dynamic. To avoid manual provisioning of addresses, operators could provision point-to-point pseudo-wires between the ATM switches that directly connect to the MPLS core, and run PNNI routing and signaling on these pseudo-wires. However, for several reasons that might be undesirable. Firstly, the ATM network islands may belong to different administrative domains. Secondly, even within one administrative domain, an operator might not want to create one single, large ATM network because of scaleability concerns. Thirdly, the introduction of an MPLS core creates a topological challenge that does not exist in traditional ATM networks. The overlay approach results in a full mesh of O(N*N) PNNI routing adjacencies, where N is the number of ATM switches that directly connect to the MPLS core. Each ATM switch that is directly connected to the MPLS core has to deal with O(N) adjacencies, where N can be quite large, thereby imposing a scaling burden on its ATM control plane. BGP [BGP4-PRO] provides a scalable approach to exchange ATM reachability information between the ATM networks over the MPLS core, preferably via BGP route reflectors [BGP-RFLC]. This approach might also be desirable to service providers who want to use a common control and management plane infrastructure to provide multiple network services over a common IP/MPLS core. This document defines MP-BGP procedures that govern this exchange of draft-ck-bgp-atm-nlri-01.txt [Page 2] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 ATM reachability information. 2. Reference Model The reference model for the connection of ATM network islands over an MPLS core is defined in [ATM-MPLS]. A common deployment scenario is outlined here for the purpose of illustrating the details of using BGP to exchange ATM reachability information. However, other deployment scenarios are not precluded. +----+ +--------| RR |---------+ | +----+ | | | IBGP IBGP | | | | +-----+ +-----+ +----+ +-----+ +-----+ | AN1 |--PNNI--| PE1 |-----|MPLS|------| PE2 |--PNNI--| AN2 | +-----+ +-----+ |Core| +-----+ +-----+ +----+ AN1 and AN2 are ATM network islands that are connected to a common MPLS core. PE1 and PE2 are MPLS provider edge devices that connect to the ATM sub-networks and are capable of running PNNI or other ATM protocols towards the ATM networks and IP/MPLS protocols in the MPLS core. PE1 and PE2 peer with a route reflector (RR) to exchange ATM network reachability information using BGP. One can also envision topologies where there is a full mesh of BGP sessions between the PEs instead of a route reflector, even though having a route reflector is highly recommended as it greatly enhances BGP control plane scaling. Each PE advertises ATM reachability information to the route reflector with the local address of the BGP peering as the nexthop. When an ATM network is multi-homed to the MPLS core, it is possible for multiple PEs to advertise the same ATM reachability information with their local address as the nexthop. When this information is re-advertised by a route reflector, some of this information is filtered as BGP advertises only best path information as determined by BGP path selection criteria. However, it is desirable for PEs to get ATM reachability information from all other PEs, so that ATM control plane has full knowledge of all the PEs that can be used to reach a particular ATM destination. For this reason, a route distinguisher (RD) as defined in [MPLS-VPN] must be added to the ATM reachability information by each advertising PE. The RD used by a PE draft-ck-bgp-atm-nlri-01.txt [Page 3] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 must be unique, and can either be preconfigured or auto-generated based on PE's attributes like configured autonomous system (AS) and IP addresses. The RD also serves to keep ATM reachability information from different ATM domains unique in the MPLS control plane. 3. Encoding ATM reachability information ATM routing information is advertised in BGP update messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [MBGP-EXT]. The pair used to identify this NLRI is to be assigned by IANA. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 255 bits that is structured as follows, +-----------------------------------------+ | Route Distinguisher (8 octets) | +-----------------------------------------+ | ATM reachability type (1 octet) | +-----------------------------------------+ | ATM reachability entry (<= 23 octets) | +-----------------------------------------+ Where, 1) Route Distinguisher is encoded as defined in [MPLS-VPN]. 2) ATM reachability type is encoded as follows, 0 to 127: Standard ATM address types 1. ATM NSAP addresses 2. Native E.164 address 3. Native X.121 address 128 to 255: Vendor specific ATM address types 3) ATM reachability entry carries the actual information. The size of this entry (in bits) can be derived by subtracting the size of the Route Distinguisher and ATM reachability type in bits ((8 + 1) * 8 = 72) from the length of the prefix. ATM reachability entries that are not a multiple of 8 bits should be zero-padded at the end to reach an octet boundary. The Next Hop field of the MP_REACH_NLRI attribute shall be interpreted as an IPv4 address, whenever the length of the Nexthop draft-ck-bgp-atm-nlri-01.txt [Page 4] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 address is 4 octets, or as an IPv6 address, whenever the length of the Nexthop address is 16 octets, or as an NSAP address if the length of the Nexthop address is 20 octets. 4. Encoding other ATM information In addition to the ATM reachability information carried in the MP_REACH_NLRI, other kinds of ATM information need to be carried as well. 4.1. ATM administrative weight A BGP speaker that advertises ATM reachability information across an MPLS core may include an ATM administrative weight that indicates the cost in the ATM network domain to reach the destination from the advertising BGP speaker. An extended community [EXT-COMM] is used to carry this information along with the advertised ATM reachability information. The administrative weight value is encoded as an opaque extended community as follows, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 | Sub-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admin Weight Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Type field = 0x03 to indicate an opaque extended community value that is transitive in nature and an IANA assignable type using the "First Come First Serve" policy, Sub-type field, whose value is to be assigned by IANA, to indicate that this community carries the ATM administrative weight, and Value field of 6 octets is encoded as follows - the first 2 octets are reserved for future use and must be set to zero and the next 4 octets encode the value of the ATM administrative weight. draft-ck-bgp-atm-nlri-01.txt [Page 5] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 4.2. ATM domain information When an MPLS core is being used to interconnect ATM networks from different ATM domains, then a mechanism is needed to restrict the exchange of routing information to ATM switches of the same domain. Route Targets as defined in [MPLS-VPN] can be used for this purpose. The Route Target is an attribute carried in the BGP Update messages. A BGP speaker will only accept routes with those route targets that it is configured to accept. Furthermore, route targets allow the BGP speaker to isolate reachability information from different domains. By assigning a different Route Target to each independent ATM network domain, the service provider can enforce that only ATM switches in the same network exchange routing information. The Route Distinguisher(RD) in the ATM prefix serves to keep ATM reachability information unique across all ATM domains. 5. Site of Origin When an ATM network island is connected to the MPLS core through two or more PEs, addresses advertised by one PE could be re-injected as PNNI exterior reachable addresses into the same ATM network island by another PE. Depending on other policies that the operator has in place, this may or may not be desirable. To avoid that addresses are re-advertised in the same ATM network island, PEs MAY include a Route Origin Community attribute (see [EXT- COMM]) or, as it is also called, a Site of Origin attribute. 6. Operation over a Multi-AS/Multi-provider MPLS core The operation over a multi-AS/multi-provider core is further study and will be added in a future version of this document. draft-ck-bgp-atm-nlri-01.txt [Page 6] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 7. Security Considerations The extensions defined in this document allow BGP to propagate ATM reachability information. As such, no new security issues are raised beyond those that already exist in BGP-4 and its use with IPv4 and IPv6. 8. IANA Considerations This document introduces a new BGP to carry ATM reachability information. The values have to be assigned by IANA. Also a new opaque extended community is used to carry ATM metric information. The subtype field for this opaque extended community has to be assigned by IANA. 9. Acknowledgments The authors would like to thank Kireeti Kompella, Nikhil Shah, Arthi Ayyangar, Rahul Aggarwal, Ying Huang, and others for useful discussions on the subject, their review and comments. 10. References 10.1. Normative References [ATM-MPLS] Metz, C. ATM and Frame Relay to MPLS Control Plane Interworking. MPLS Forum, mpls2004.063.01. July 2004 [MPLS-VPN] Rosen et al., BGP/MPLS VPNs, IETF draft-ietf-l3vpn-rfc2547bis-01.txt. September 2003 [MBGP-EXT] Bates et al., Multi-protocol extensions for BGP-4. IETF, draft-ietf-idr-rfc2858bis-06.txt, November 2004 [EXT-COMM] Sangli et al., BGP Extended Communities Attribute, IETF draft-ietf-idr-bgp-ext-communities-07.txt. September 2004 [BGP4-PRO] Rekhter, Y., Li, T., et al., A Border Gateway Protocol 4 (BGP4), IETF, draft-ietf-idr-bgp4-23.txt [BGP-RFLC] Bates, T., Chandra, R., Chen, E., BGP Route Reflection - An Alternative to Full Mesh IBGP, IETF RFC 2796, April 2000 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate draft-ck-bgp-atm-nlri-01.txt [Page 7] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [BGP4-CAP] Chandra, R., Scudder, J., Capabilities Advertisement with BGP-4, IETF, RFC 3392, November 2002. 11. Author Information Chaitanya Kodeboyina Juniper Networks 1194 North Mathilda Ave Sunnyvale, CA 94089 Email: ck@juniper.net Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 Email: chmetz@cisco.com Peter B. Busschbach Lucent Technologies 67 Whippany Road Whippany, NJ, 07981 Email: busschbach@lucent.com 12. Intellectual Property 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 assurances 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 draft-ck-bgp-atm-nlri-01.txt [Page 8] Internet Draft draft-ck-bgp-atm-nlri-01.txt November 2004 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. 13. Disclaimer of Validity 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 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. Copyright Statement Copyright (C) The Internet Society (2004). 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. 15. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-ck-bgp-atm-nlri-01.txt [Page 9]