Internet Draft Z. Bo Tang
Expiration Date: September, 2000 Debanjan Saha
Bala Rajagopalan
Tellium Inc.
Extensions to CR-LDP for Path Establishment in Optical Networks
draft-tang-crldp-optical-00.txt
1. 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.
2. Abstact
This draft describes the extensions to the CR-LDP for establishing
optical switched paths (OSP). This document does not advocate CR-LDP
as the sole mechanism for setting up such paths. RSVP extensions for
path set-up are described in [1].
3. Introduction
This document describes the extensions to CR-LDP [2] for
establishing switched paths in optical networks. The optical network
model considered in this draft consists of multiple Optical Cross-
Connects (OXCs) interconnected by optical links in a general
topology referred to as an "optical mesh network". In general, it
can be expected that topologically adjacent OXCs in an optical mesh
network will be connected via multiple, parallel bi-directional
links. Each link can carry one or more optical channels or
wavelengths. Each wavelength can be further demultiplexed into
multiple TDM channels. We also assumed that one or more control
channels exist between neighboring OXCs for signaling purposes.
Tang, et al. [Page 1]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
Each OXC is capable of switching a wavelength from a given input
port to a given output port. This switching function is controlled
by appropriately configuring a cross-connect table. In the most
general case, the cross-connect table consists of entries of the
form <input port i, wavelength j, sub-channel k, output port m,
output wavelength n, output sub-channel p>, indicating that the TDM
channel k, in wavelength j entering input port i will be switched to
TDM channel p in output wavelength n at output port j. An "optical
path" from an ingress port in an OXC to an egress port in a remote
OXC is established by setting up suitable cross-connects in the
ingress, the egress and a set of intermediate OXCs such that a
continuous physical path exists from the ingress to the egress port.
Automated establishment of optical paths involves setting up the
cross-connect table entries in the appropriate OXCs in a coordinated
manner such that the desired physical path is realized. The request
to establish an optical path may arise from either a router (or some
other device) connected to the OXCs or from a management system.
Such a request must identify the ingress and the egress OXC as
endpoints of the optical path. In addition, it may also optionally
specify the input and output ports, wavelengths, and TDM channels.
The request may also include bandwidth parameters and channel type
(e.g., OC-48/OC-192, 10 GE/N), reliability parameters, restoration
options, setup and holding priorities for the path etc. On receipt
of the request, the ingress OXC computes a suitable route for the
requested path, following applicable policies and constraints. Once
the route has been computed, the ingress invokes CR-LDP to set up
the path.
4. Overview of the Extensions
4.1 Overview of the Key Concepts and Semantics of the CR-LDP
First, it is necessary to review the semantics of some of the CR-LDP
concepts [2, 4] in the optical network setting:
o Label: Under MPLS, labels are used for packet forwarding. Labels
are autonomously administered by each MPLS LSR [4]. In the context
of setting up an optical path, the labels as defined in [2] are no
longer directly applicable.
o FEC: As per [2] and [4], Forwarding Equivalence Class is captured
in the label used, and all packets classified as belonging to the
same FEC will be forwarded with the same label. There is no
similar semantics in optical networks.
o Label mapping/binding: The main function of LDP/CR-LDP is to
assign and distribute Label-FEC mapping information among LSRs. In
optical networks, the equivalent function is the assignment of
input or output ports for paths by optical switches and the
communication of this information to the appropriate neighbors.
o Label Request message: As described in [2, 4], a Label Request
Tang, et al. [Page 2]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
message is used by an upstream LSR to request a label binding from
the downstream LSR for a specified FEC and CR-LSP. In optical
networks, a Label request message may be used by the upstream OXC
to request a port (and wavelength) assignment from the downstream
OXC for the optical path being established. Such a Label request
message may carry all the information presently defined under CR-
LDP except the TE-TLV which is not relevant. Using downstream-on-
demand and ordered control mode, a Label request message is
initially generated at the ingress OXC and is propagated to the
egress OXC.
o Label Mapping message: As described in [2, 4], a Label Mapping
message is used for a downstream LSR to distribute label mapping
information to its upstream peer. In optical networks, a Label
mapping message is first generated by the egress OXC. It indicates
the port (and wavelength) assignment to the upstream peer for the
specified path. After receiving a Label mapping message, an
intermediate OXC selects an input port and connects it to the
appropriate output port derived from the port indication received
from the downstream OXC. It also sends a Label mapping message to
its upstream peer indicating the selected input port (and
wavelength). It is implicitly assumed here that each OXC knows the
identity of its output port that connects to a given input port of
a neighbor [3]. This indeed is the dependency in label assignment.
A protocol is required to determine the port mappings.
4.2 Overview of Extensions
The proposed extensions to the CR-LDP are aimed at accomplishing the
following tasks.
o Signaling Port ID: A new TLV(OPTICAL_LABEL) is introduced to
specify ports to be assigned for setting up the path. Such a
"label" must be assigned in a coordinated manner by a pair of
adjacent OXCs [3], since the "label" at one OXC is tied to a
specific "label" at a neighboring OXC based on physical
connectivity.
o Signaling optical switched path identifier: A new TLV (OSP_ID) is
introduced to provide the identifier to the optical path being
established. The OSP_ID TLV is independent of LSP_ID TLV of the
base CR-LDP. This provides the flexibility of establishing LSPs on
the top of an optical path being setup when needs arise.
o Signaling the two end points of the path being set up: A new TLV
(END_POINTS) is introduced to signal the two end points at the
port level of the optical path. When the two end points are
already selected before the path is set up, at least the port
already selected for the egress node should be propagated to the
egress node.
o Signaling requirements for both span and path protection: A new
TLV (PROT_REQ) is introduced to signal what protection levels are
Tang, et al. [Page 3]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
required for both span (or local) and path protection. Examples of
span (or local) protection include SONET 1+1 and 1:N APS. Examples
of path protection include various levels regarding how an
alternate path is shared such as in a style of 1+1 or 1:N
analogous to span protection. The values indicating both span and
path protection levels encapsulated in the TLV are opaque to the
extended CR-LDP process and are interpreted by the "protection
policy controller".
o Recording the precise route of the path being established: A new
TLV (ROUTE_RECORD) is introduced to capture the precise route of
the path being set up with port level information. This is done by
letting each OXC insert its node ID and the both output and input
port selected for the path in the Label Mapping message. The
message received by the ingress OXC will have the complete route
at the port level. This information is useful for network
management functions.
5. Configuration Recommendations to the Base CR-LDP Specification
5.1 Multiple Hello Adjacencies per LDP Session
It is very likely that neighboring OXCs will have multiple physical
links between them. In this case, only a single LDP session between
the two LDP peers will be established. A Hello Adjacency should be
maintained for each physical connection between the two adjacent
OXCs.
6. Extended Protocol Specifications
6.1 Optical Label TLV
Optical Label TLV is used to specify the output port ID and the
associated wavelength when an OXC sends a Label Mapping message to
its upstream peer for a path setup.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Optical Label ( TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength ID | Sub-channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port ID
32-bit field.
Wavelength ID
16-bit field.
Sub-channel ID
Tang, et al. [Page 4]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
16-bit field.
6.2 OSP ID TLV
The TLV is used to provide the identifier to the optical path being
established. The format is similar to that of LSP_ID TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| OSPID (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D| Local OSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress OSP OXC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (14 bits)
TBD
Length (16 bits)
Specifies the length of the value field in bytes.
Reserved (15 bits)
Zero on transmission. Ignored on receipt.
D (1 bit)
Direction dimension indicator of the path.
0: indicates unidirection path being set up
1: indicates bidirection path being set up
Local OSP ID (16 bits)
The Local OSP ID is locally unique
within the Ingress OXC originating the OSP.
Ingress OSP OXC ID (32 bits)
This node ID with the Local OSP ID provide the unique
identifier of the OSP within the network.
6.3 Endpoints TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ENDPOINTS (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress OSP OXC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress OSP OXC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port ID at the Ingress OXC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port ID at the egress OXC |
Tang, et al. [Page 5]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ingress OXC ID (32 bits)
Ingress OXC ID together with the other IDs provide the two end
point addresses for the path.
6.4 Protection Requirement TLV
This new TLV is present in the Label Request message to indicate
which protection mode is requested for the optical path.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Protection Req.( TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocalProt.Mode|Path Prot. Mode| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Protection Mode (8 bits)
The value is opaque to CR-LDP process and is used by the local
"protection controller" for local protection configuration.
Path Protection Mode (8 bits)
The value is opaque to CR-LDP process and is to inform the OXC
receiving the TLV what protection level is associated with the
optical path.
Sub-TLVs
Sub-TLVs can be used to provide and identify the associations
among the paths that are under the specified protection scheme.
The format details are to be determined.
6.5 Route Record TLV
The encoding for the Route Record TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Route Record ( TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OXC ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In port of OXC ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out port Id of OXC ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OXC ID n //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In port of OXC ID n |
Tang, et al. [Page 6]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out port of OXC ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One or more OXC IDs
A list of router-ids indicating the path of OXCs the message has
traversed.
One or more in port IDs
A list of port IDs indicating the incoming ports of OXCs for the
optical path.
One or more out port IDs
A list of port IDs indicating the out going ports of OXCs for the
optical path.
7. Issues
7.1 Bidirectional Path Establishment
CR-LDP is designed under the assumption that explicit LSPs are
fundamentally unidirectional and point-to-point virtual path
connection abstraction. In optical networks, it is currently common
practice that an optical path set up is in fact bi-directional.
Racing condition that will not occur at unidirectional cases with
MPLS downstream on demand and ordered control mode for label
distribution can happen for bi-directional cases. We propose a
simple solution to avoid racing condition.
The solution suggests forming a master and slave relationship
between two adjacent OXCs. The OXC with the higher node ID is the
master to the other. It is always the master node that makes port
assignment for both itself and its slave peer.
6.2 Improve Availability of MPLS control plan.
An availability issue may rise when the MPLS control plan is down
and then comes back a while later. All relevant databases
containing the information prior to the breakdown should be
recovered. The solution is TBD.
7. Acknowledgements
The ideas and texts presented in this document are stimulated from a
numerous discussions. Particularly, we would like to thank Mike
Rugiero and Tom Damiano.
8. References
[1] D. Saha, B. Rajagopalan, and B. Tang, "RSVP Extensions for
Signaling Optical Paths", draft-saha-rsvp-optical-signaling-00.txt,
March, 2000.
Tang, et al. [Page 7]
Internet Drat draft-tang-crldp-optical-00.txt March 2000
[2] L. Andersson, A. Fredette, B. Jamoussi, et al., "Constraint-
Based LSP Setup using LDP", Work in Progress, January, 1999.
[3] B. Rajagopalan, D. Saha, B. Tang, and K. Bala, "Signaling
Framework for Automated Establishment and Restoration of Paths in
Optical Mesh Networks," draft-rstb-optical-signaling-framework
00.txt, March, 2000
[4] L. Anderson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP
Specification", Work in Progress, October, 1999.
[5] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control With
Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt.
9. Author's Addresses
Z. Bo Tang
Debanjan Saha
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Ocean Port, NJ 07757
Email: {btang, dsaha, braja}@tellium.com