Network Working Group Marc Blanchet
Internet Draft Florent Parent
Expiration: August 2001 Viagenie
Bill St-Arnaud
Canarie
March 2001
Optical BGP (OBGP): InterAS lightpath provisioning
draft-parent-obgp-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 work investigates inter-AS lightpath provisioning using BGP. BGP
is currently deployed across the different autonomous systems on the
Internet, so investigating how a BGP approach to provision lightpaths
across autonomous systems is of great interest. This work proposes
extensions to BGP to this end.
1. Introduction
Much of the current work in IP optical focuses on using interior
gateway protocols such as ISIS and OSPF with TE extensions for routing
and GMPLS for signaling [ISIS-TE], [OSPF-TE], [CRLDP], [RSVP-TE].
This draft considers optical lightpath provisioning at the inter-AS
scope. Other protocols may be use inside the autonomous system to
control the actual optical cross-connect (OXC).
BGP [BGP] is currently deployed across the different autonomous
systems on the Internet, so investigating how a BGP approach to
provision lightpaths across autonomous systems is of great interest.
The goal of this work is to propose a BGP approach to lightpath
provisioning.
2. Scope
The traditional networks are carrier based and the carrier manages the
customer transit connectivity. Customers are now acquiring fibre,
optical switch ports and wavelengths and this changes the traditionnal
model of network peering.
Customers in sites can now own their own wavelengths, and eventually
optical switch ports. Providers can deploy an optical infrastructure
and sell wavelengths and optical switch ports to their
customers. Customers now have multiple wavelengths and optical ports
from one or many providers.
This ownership of wavelengths and optical ports now brings new
operational requirements where customers at the edge need to control a
subset of lightpaths within another network's wavelength cloud
(provider) so that they can manage their own lightpath routing within
that cloud.
This new model allows distributed Internet Exchange facilities using
the exchange and trading of lightpaths between networks to minimize
the need for hierarchical network architectures to interconnect
peering networks. As an example, CA*net4 optical network in Canada
could provide lightpath transit to Renater/France and Wide/Japan
networks.
The scenario that is considered in this document is where autonomous
sites own their wavelengths and optical switch ports. End customer
have "virtual" control over its optical switches/ports/wavelengths.
The document covers inter-AS provisioning using BGP. Inside an
autonomous system, other protocols can be used, such as OSPF or ISIS
with TE extensions for routing and GMPLS for signaling.
3. Protocol operation
It is assumed that a BGP peering is already established between
participating sites, either using a non-optical path or a
pre-configured optical path between sites. This BGP peering will be
used in the following description.
The (egress) OXC are BGP speakers. The OXC and the BGP router are
closely tied together in the sense that information received from BGP
will be used to establish optical cross-connects inside the OXC.
The sites are eBGP peers. This document doesn't specify any intra-AS
routing and signaling protocols for lightpath provisioning, although
interaction between the inter-AS and intra-AS protocols will need to
be defined.
The protocol proposes two phases.
The first phase is the lightpath reachability phase. During this
phase, sites advertise through BGP the availability of the optical
lightpath to their site. These announcements will contain information
on the OXC and the available lightpath through that OXC. The
information will be encoded using multiprotocol BGP extensions and
extended community.
This first phase will allow sites to build up a "lightpath RIB" that
will be used to determine if a lightpath is feasible across a number
of OXC in different sites.
The second phase is the lightpath establishement. This phase uses the
information received from the lightpath reachability phase and then
uses a BGP update message to communicate the lightpath establishement
to the OXC sites on the path. The information will be encoded using
multiprotocol BGP extensions and extended community.
4. Encoding Optical Lightpath information in BGP
The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes
from multiple "address families".
This document proposes to use MP-BGP extensions to encode the NLRI
such that the necessary optical and routing information can be
propagated in BGP. Figure 1 presents the MP_REACH_NLRI attribute
format.
+----------------------------------------------------+
| Address Family Identifier (2 octets) |
+----------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+----------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+----------------------------------------------------+
| Network Address of Next Hop (variable) |
+----------------------------------------------------+
| Number of SNPAs (1 octet) |
+----------------------------------------------------+
| SNPA |
~ ~
+----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+----------------------------------------------------+
Figure 1.
The address family identifier (AFI) represents the type of network
layer protocol used in the protocol. Since IP is used, the AFI value
is either 1 for IPv4 addresses or 2 for IPv6 addresses.
The subsequent address family identifier (SAFI) indicates what type of
information is carried in the NRLI. The NLRI will encode the necessary
information about the optical cross-connect (OXC) endpoint and the
reachable networks through that OXC. This document proposes using a
SAFI value of 131, which is part of the private use range. If this
proposal goes to standard track RFC, then an IANA assigned number
should be defined as defined in [BGP-MP].
The necessary information to be carried inside BGP are:
- the IP address of the site egress OXC
- The reachable IP prefixes
- A lightpath identifier
The following sections will describe each of those items.
4.1 IP address of the local OXC and reachable IP prefixes
The update message includes the IP address of the local OXC. This
allows a site to determine if a lightpath has already been established
to the destination OXC [OROUTING]. The IP address of the local OXC is
encoded in the NLRI as showned in figure 2.
The reachable IP prefixes are used by remote sites to determine what
networks can be reached through the announced lightpath
availability. The reachable IP prefixes are carried in the NLRI, also
showned in figure 2.
+----------------------------------------------+
| Length of the NLRI (2 octets) |
+----------------------------------------------+
| Length of OXC IP address (2 octets) |
+----------------------------------------------+
| OXC IP address (variable) |
+----------------------------------------------+
| Length of Reachability Entries (2 octets) |
+----------------------------------------------+
| First Reachability Entry (variable) |
+----------------------------------------------+
| Second Reachability Entry (variable) |
+----------------------------------------------+
.....
+----------------------------------------------+
| N-th Reachability Entry (variable) |
+----------------------------------------------+
Figure 2: NLRI encoding
Length of the NLRI (2 octets):
Total length of the NLRI
Length of OXC IP address (2 octets):
Length of the OXC IP address
OXC IP address (variable):
IP address of the OXC
Length of Reachability Entries (2 octets):
Length of a reachability entry
Reachability Entry (variable):
Variable length field that lists the feasible routes associated with
this update. This is encoded as an NLRI tuple of the form
<length,prefix> as described in [BGP-MP].
4.2 Lightpath identifier attribute
A site can have one or many lightpaths available to its neighbor OXC.
The site may decide to send one message that aggregates all its
available lightpaths in one BGP message, or the site may make
available some lightpaths for special usage and others for general
use.
The lightpath reachability update message identifies the lightpath or
lightpath bundle using an extended community attribute
[BGP-COMM]. Figure 3 shows the format of the lightpath identifier
attribute. The extended community attribute is 8 octets long.
+--------------------------------------+
| Type (2 Octets) |
+--------------------------------------+
| source AS (2 Octets) |
+--------------------------------------+
| reserved (2 Octets) |
+--------------------------------------+
| Lightpath identifier (2 Octets) |
+--------------------------------------+
Figure 3: Extended community for lightpath identifier
The lightpath identifier can also be used to enforce local policies
where a site wants to reserve a number of optical ports for special
purposes. In that case, a predefined lightpath identifier can be used
between participating sites.
The lightpath identifier attribute will be used during both the
lightpath reachability and the lightpath establishement phases.
The value(s) and length of the lightpath identifier attribute will
need to be further defined.
4.3 Capability Negociation
A BGP speaker that uses the BGP messages described in this document
should use the capability advertisement defined in [BGP-CAP]. This
will allow a speaker to determine if a peer supports the multiprotocol
extensions defined in this document. The capability negociation should
use the AFI and SAFI values of (to be completed)
5. First phase: Lightpath reachability
In this first phase, the sites advertise lightpath availability to
other sites using BGP lightpath reachability update messages. This
message contains the following information:
- The IP address of the site egress OXC
- The reachable IP prefixes
- A lightpath identifier
The IP address of the site egress OXC and the reachable IP prefix
through that announced lightpath are encoded as described in section
4.1.
The lightpath identifier is an extended community attribute encoded as
described in section 4.2. The type field uses a value of 0xA101 to
denote that the message contains a lightpath reachability message. The
type field value is chosen from the vendor-specific range [BGP-COMM].
If this proposal goes to standard track RFC, then an IANA assigned
number should be defined as defined in [BGP-COMM].
The reserved field has a value of 0x00 when the type field is 0xA101
(lightpath reachability message).
The lightpath identifier value is assigned by the local organisation.
+--------------------------------------+
| Type (2 Octets) = 0xA101 |
+--------------------------------------+
| source AS (2 Octets) |
+--------------------------------------+
| 0x00 |
+--------------------------------------+
| Lightpath identifier (2 Octets) |
+--------------------------------------+
Figure 4: Extended community for lightpath identifier
The following is an example of BGP speakers connected together through
the connexions shown in figure 5.
A ----- X ----- Y ----- Z ----- B
\ /
\ /
W ------- U
Figure 5.
To illustrate the process, the following table shows what the
local-RIB at sites A and U would look like when updates from all sites
are received.
Note that the extended-community shows the type 0xA101 (lightpath
reachability message), the AS number of the originating site and a
lightpath identifier.
The identifier used here is of the form L(xa) and represents one or a
bundle of available optical ports on the originating site (in this
case, site X). The value of this identifier is choosen by the local
site.
Destination OXC_IP Next-Hop extended-community AS-path
----------- ------ -------- ------------------ -------
Network X IP_X IP_X 0xA101,X,L(xa) X
Network Y IP_Y IP_X 0xA101,Y,L(yx) X,Y
Network Z IP_Z IP_X 0xA101,Z,L(zy) X,Y,Z
Network B IP_B IP_X 0xA101,B,L(bz) X,Y,Z,B
Network W IP_W IP_X 0xA101,W,L(wx) X,W
Network U IP_U IP_X 0xA101,U,L(uw) X,W,U
Table 1. Local-RIB at site A
Destination OXC_IP Next-Hop extended-community AS-path
----------- ------ -------- ------------------ -------
Network Z IP_Z IP_Z 0xA101,Z,L(zu) Z
Network B IP_B IP_Z 0xA101,B,L(bz) Z,B
Network Y IP_Y IP_Z 0xA101,Y,L(yz) Z,Y
Network W IP_W IP_W 0xA101,W,L(wu) W
Network X IP_X IP_W 0xA101,X,L(xw) W,X
Network A IP_A IP_W 0xA101,A,L(ax) W,X,A
Table 2. Local-RIB at site U
Each site is responsible of sending its lightpath availability to its
neighbors. If a OXC can no longer offer a previously announced
lightpath, it must send a withdrawl. That withdrawl message will contain
the same extended-community attributes that were used to announce the
previously available lightpath(s).
After receiving BGP update messages from its neighbors, a site can
choose to request the establishement of a lightpath to that
destination sending a lightpath establishement BGP update message.
6. Second phase: Lightpath establishement
This work investigates inter-AS lightpath provisioning. BGP is
currently deployed across the different autonomous systems on the
Internet, so investigating how a BGP approach to provision lightpaths
across autonomous systems is of great interest.
The goal of this work is to propose a BGP only approach to lightpath
provisioning. To this end, this section describes extensions to BGP to
signal lightpath establishment between autonomous systems.
6.1 Using BGP for lightpath establishment
Following the lightpath reachability phase, a site has the following
information for each candidate lightpath:
- The reachable IP prefixes through that candidate lightpath
- The IP address of the destination site egress OXC
- A lightpath identifier
- The AS_PATH to the destination site
A site can choose to request the establishment of a lightpath from
the information received in the lightpath reachability phase. The
reachable IP prefix(es) can be used to determine which networks can be
reached through the lightpath if that lightpath is established.
The IP address of the destination site egress OXC can be used to
determine if a lightpath to the OXC has already been established.
To illustrate the proposed protocol mechanisms, the following
optical topology example is used:
A ----- X ----- Y ----- Z ----- B
\ /
\ /
W ------- U
Looking more closely at site A, the following local-RIB is formed from
the information in the reachability phase:
Destination OXC_IP Next-Hop extended-community AS-path
----------- ------ -------- ------------------ -------
Network X IP_X IP_X 0xA101,X,L(xa) X
Network Y IP_Y IP_X 0xA101,Y,L(yx) X,Y
Network Z IP_Z IP_X 0xA101,Z,L(zy) X,Y,Z
Network B IP_B IP_X 0xA101,B,L(bz) X,Y,Z,B
Network W IP_W IP_X 0xA101,W,L(wx) X,W
Network U IP_U IP_X 0xA101,U,L(uw) X,W,U
If site A wants to establish a lightpath to network U, Site A needs to
first lookup the "lightpath RIB" entries to find a complete path to
the site. The "lightpath RIB" entry for network U on the last line
shows that the AS-path is (X,W,U).
In order to establish a lightpath to site U, A need to do the
following steps:
1- Lookup the RIB entry for the destination site
2- Lookup the corresponding entries for the intermediary sites
3- Allocate optical port and create a BGP "establish" message using
the looked up information.
In the example, step 1 will lookup the entry:
Destination OXC_IP Next-Hop extended-community AS-path
----------- ------ -------- ------------------ -------
Network U IP_Z IP_X 0xA101,Z,L(uw) X,W,U
Step 2 will lookup for the intermediate sites, that is the path to (X)
and to (X,W):
Destination OXC_IP Next-Hop extended-community AS-path
----------- ------ -------- ------------------ -------
Network X IP_X IP_X 0xA101,X,L(xa) X
Network W IP_W IP_X 0xA101,W,L(wx) X,W
The reason for looking up the intermediate sites entries in the
"lightpath RIB" is to make sure that there is a complete path
available to the destination site. Lightpath availability on the
optical network may change at any time.
For example, if the state of site W were to change such that
lightpaths were no longer available to reach X from W, W must withdraw
its lightpath availability by sending BGP withdrawl of its own
lightpath, L(wx) in the example. If that were the case, X would now
advertise to A a different path to reach U (X,Y,Z,U) using the
standard BGP path selection process.
The BGP update message used to establish a specific lightpath contains
the AS_PATH information and the lightpath identifiers obtained in the
lightpath reachability phase. These information are encoded in
extended community attributes.
+--------------------------------------+
| Type (2 Octets) = 0xA102 |
+--------------------------------------+
| source AS (2 Octets) |
+--------------------------------------+
| destination AS (2 Octets) |
+--------------------------------------+
| Lightpath identifier (2 Octets) |
+--------------------------------------+
Figure 4: Extended community for lightpath establishment message
Destination OXC_IP Next-Hop extended-community AS-path
----------- ------ -------- ------------------ -------
Network X IP_X IP_X 0xA101,X,L(xa) X
Network W IP_W IP_X 0xA101,W,L(wx) X,W
Network U IP_Z IP_X 0xA101,Z,L(uw) X,W,U
In order to establish the lightpath, site A must send a BGP update
message to its neighbor(s). Site creates a BGP update message using
the following extended community attribute:
type src AS dest AS lightpath id
---- ------ ------- ------------
0xA102 A X L(xa)
0xA102 X W L(wx)
0xA102 W U L(uw)
The lightpath establishment message is detected by the presence of
the extended community attribute type 0xA102.
Site A allocates an optical port to be used for the lightpath. This
port must be identified to its neighbor OXC. Site A will do that by
setting an appropriate the value for L(xa). This assumes that there
are some peering/trust relationships between neighboring OXC such that
some convention will be agreed upon between such neighbors.
Note that the value of L(xa) for this example may and will probably be
different from the L(xa) value obtained from the lightpath
reachability phase. The lightpath establishment phase requires precise
optical port assignements between the neighbors and this is the
proposed function here. The port assignement is of local scope and is
significant only to neighboring OXC.
Site A sends the BGP message to its neighbors. Upon receiving a
lightpath establishment update message, a BGP peer should discard the
message if its AS is not part of the destination AS in the extended
community attribute. This way, the establishment update message gets
processed only by the identified AS in the attribute.
Upon receiving the update, OXC X will have the information to do the
cross-connect to site A using the value L(xa), and assign an optical
port from the requested "bundle" L(wx). Again, OXC X will set the
value for L(wx) that identifies the allocated optical port.
The local RIB of each OXC will have a new entry that identifies the
establish/allocated lightpath.
6.2 Using RSVP-TE or CR-LDP for lightpath establishment
(to be completed)
The purpose of this section is to look at current signaling protocols
to provision lightpaths and how they could be used in the inter-AS
context, define the interaction with BGP.
7. Routing information exchange
When the lightpath is established, a new BGP peeringis established
between the two peers that are now directly connected together on the
new established lightpath.
8. Interaction with Intra-AS IPO protocols
Since the lightpath to be established can cross multiple ASes, then
there should be propagation of the requested lightpath inside the
crossed AS. This should be done by redistributing the lightpath
request parameters in the IPO intraAS protocol
(to be completed)
9. Issues to be solved
- how to unprovision: through a withdrawal, but details to be
discussed
- multiple reservations at the same time, reservations not being used
that should be discarded: typical reservation problems.
- Lightpath identifier: currently an extended attribute. Encode in
MP_NLRI instead ?
10. References
[OBGP] CA*Net4, Bill St-Arnaud.
[BGP4] Y. Rekhter, et al., "A Border Gateway Protocol 4 (BGP-4)", Work
in Progress, draft-ietf-idr-bgp4-12.txt, Jan 2001
[BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute",
Work in progress, draft-ramachandra-bgp-ext-communities-08.txt,
February 2000
[BGP-MP] Bates, T., et al., "Multiprotocol Extensions for BGP4", RFC
2858, June 2000.
[BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with
BGP-4" RFC 2842, May 2000
[OROUTING] Dimitris Pendarakis, et al., "Routing Information Exchange
in Optical Networks", Work in Progress, draft-prs-optical-routing-01.txt
[BGPVPN] Hamid Ould-Brahim, et al., "Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs", Work in Progress,
draft-ouldbrahim-bgpvpn-auto-00.txt, November 2000.
[CRLDP] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling -
CR-LDP Extensions", Work in Progress,
draft-ietf-mpls-generalized-cr-ldp-00.txt, November 2000.
[RSVP-TE] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling -
RSVP-TE Extensions", Work in Progress,
draft-ietf-mpls-generalized-rsvp-te-00.txt, November 2000.
[ISIS-TE] Kompella, K., et. al. "IS-IS Extensions in Support of
Generalized MPLS", Work in Progress,
draft-ietf-isis-gmpls-extensions-01.txt, November 2000.
[OSPF-TE] Kompella, K., et. al. "OSPF Extensions in Support of
Generalized MPLS", Work in Progress,
draft-ietf-ospf-gmpls-extensions-00.txt, November 2000.
11. Security Considerations
- Provisioning on demand new lightpaths changes the network
infrastructure and the routing tables. This should only be done using
strong authentication.
- Authentication measures in BGP must be used.
12. Acknowledgements
The OBGP acronym, the seminal ideas as well as most of the thinking
are from Bill St-Arnaud.
13. Authors' Addresses
Marc Blanchet
Viagenie
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2 Canada
Marc.Blanchet@viagenie.qc.ca
Florent Parent, Viagenie
Viagenie
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2 Canada
Florent.Parent@viagenie.qc.ca
Bill St-Arnaud
Canarie
110 O'Connor, 4th floor
Ottawa, ON, K1P 1H1 Canada
Bill.St.Arnaud@canarie.ca