Internet DRAFT - draft-ck-bgp-atm-nlri
draft-ck-bgp-atm-nlri
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
<AFI, SAFI> 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 <AFI, SAFI> to carry ATM
reachability information. The <AFI, SAFI> 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]
