Network Working Group Marc Blanchet
Internet Draft Florent Parent
Expiration: July 2001 Viagenie
Bill St-Arnaud
Canarie
January 2001
Optical BGP (OBGP): InterAS lightpath provisioning
draft-parent-obgp-00.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
Current work in IP optical focuses on designing interior gateway
protocols for use in optical, such as OSPF/TE and MPLamdaS.
(TBD: add references)
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 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.
2. Scope
- is inter-AS, not intra-AS.
- inside AS can be iBGP or IGP with IP optical extensions, MPLamdaS,
etc. Interaction between intra-AS and inter-AS protocols will need
to be defined.
- End customer own the fiber or wavelength
- End customer have "virtual" control over its optical
switches/ports/wavelengths. Some trust exists between AS that are
offering the wavelengths.
- Typical example:
a lightpath established from Renater-France through CA*net4-Canada
to Wide-Japan interAS between provinces in Canada, but intraAS
inside each province. [OBGP]
3. Requirements
TBD
4. Encoding Optical Lightpath information in BGP
The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes
from multiple "address families".
MP-BGP extensions are used to encode the NLRI such that the necessary
optical and routing information can be propagated in BGP.
+----------------------------------------------------+
| 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.
The necessary information to be carried inside BGP are:
- the IP address of the site egress OXC
- The reachable IP prefixes
- A lightpath/site 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 establish
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
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 "discovery" 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
A site may have local policies about which sites (AS) are allowed to
reserve a lightpath. As an extended community attribute, the lightpath
identifier attribute can then be used to apply such policies in BGP.
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. Protocol operation
Assume BGP peering is already established between participating
sites, either using a non-optical path or a pre-configured optical
path between sites.
In the following description, we assume that the OXC are BGP
speakers. The OXC and the BGP router are closely tied together. The
sites are eBGP peers.
The protocol proposes two phases.
The first phase is the lightpath discovery phase. During this
phase, sites advertise through BGP the availability of the optical
lightpath to their site.
The second phase is the lightpath establishement. This phase uses the
information received from the discovery phase and then uses a BGP
update message to communicate the lightpath establishement to the OXC
sites on the path. This document proposes extensions to BGP for the
lightpath establishement.
5.1 Lightpath discovery
In this first phase, the sites advertise lightpath availability to
other sites using BGP "discovery" 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 "discovery" message. The type field
value is chosen from the vendor-specific range [BGP-COMM].
The reserved field has a value of 0x00 when the type field is 0xA101
(discovery 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
When a site receives a BGP "discovery" update message, the BGP
speaker must not send that update message to its neighbor unless
there is at least one lightpath available to that neighbor. This
assures that "discovery" updates are received only if there is a
feasible lightpath to the site that sourced the update message.
As an example, in the following example if B sends "discovery"
messages to its neighbor BGP peer Z. If Z has lightpaths available to
Y but none to U, Z will send that message to Y only.
<-- <--
A ----- X ----- Y ----- Z ----- B
\ /
\ /
W ------- U
Sites receiving the lightpath discovery update know that there is a
possible lightpath to the destination site defined through is AS
number and network prefix(es). The AS_PATH constructed along the
way also contains the optical sites that the lightpath will go
through if it is established.
Upon receiving a BGP update message from a site, the destination
site can choose to request the establishement of a lightpath to
that destination sending a lightpath establishement BGP update
message.
5.2 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 will describe extensions to
BGP to signal lightpath establishement between autonomous systems.
We will also investigate and compare to current work on existing
signaling protocols, such as extensions to CR-LDP and RSVP.
TBD: Reference current working documents at IETF on proposed signaling
protocols for establishing lightpath on an IP optical network
(extensions to CR-LDP, RSVP)
5.2.1 Signaling requirements
(TBD)
5.2.3 Using BGP for lightpath establishement
Following the lightpath discovery phase, a site has the following
information for each candidate lightpaths:
- The IP address of the destination site egress OXC
- The reachable IP prefixes through that candidate lightpath
- A lightpath identifier
- The AS_PATH to the destination site
A site can choose to request the establishement of a lightpath from
the information received in the lightpath discovery phase.
The BGP update message used to establish a specific lightpath
contains the AS_PATH information and unique identifier obtained in
the discovery phase. This information should be included in a
"to-be-defined" attribute.
Upon receiving a lightpath establishement update message, a BGP
peer should discard the message it does not contain that site AS in
the attribute (tbd). This way, we make sure that the establishement
update message gets processed only by the identified AS in the
attribute.
(to be completed)
5.2.3 Using RSVP for lightpath establishement
(to be completed)
5.2.4 Using CR-LDP for lightpath establishement [CRLDP]
CR-LDP uses TCP as transport protocol. We can use CR-LDP as a
signaling protocol between the border OXC that would provide the
necessary signaling to establish the required lightpaths.
Extensions to CR-LDP are defined for support of optical lightpath
signaling. CR-LDP extensions for optical networks [CRLDP] defines the
following extensions.
These optical attributes can be obtained from the lightpath discovery
phase using BGP.
(to be completed)
6. Routing information exchange
When the lightpath is established, a new BGP process is started to
establish a new BGP peering session between the two peers that are
now directly connected together on the new established lightpath.
7. 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 (either extended IGP
or MPLS or...).
Further work has to be done on this.
8. Issues to be solved
- how to unprovision: probably 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.
- if the lightpath breaks at some point, how does the BGP session
handles this?
9. References
[OBGP] CA*Net4, Bill St-Arnaud.
[BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute",
February 2000, work in progress
[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
[RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, Sept 1997
[OROUTING] Dimitris Pendarakis, et al., "Routing Information Exchange
in Optical Networks", Work in Progress
[BGPVPN] Hamid Ould-Brahim, et al., "Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs", Work in Progress
[CRLDP] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling -
CR-LDP Extensions", Work in Progress
10. 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.
11. Acknowledgements
The OBGP acronym, the seminal ideas as well as most of the thinking
are from Bill St-Arnaud.
12. 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