MPLS Working Group Yanhe Fan, Peter Ashwood-Smith (Nortel Networks)
Internet Draft Vishal Sharma, Ken Owens (Tellabs)
Gerald R. Ash (AT&T)
Murali Krishnaswamy, Yang Cao (Lucent Technologies)
M. K. Girish (SBC Technology Resources, Inc.)
Herbert M. Ruck (Packet Network Services)
Simon Bernstein, Phuc Nguyen (Global One)
Sunil Ahluwalia (Trillium Digital Systems)
Hans Sjostrand (Ericsson)
Klas Eriksson (Utfors AB)
Lihshin Wang(QwestCommunications)
Avri Doria (Nokia Telecommunications)
Heinrich Hummel (Siemens AG)
Expiration Date: September 2000
March 2000
Extensions to CR-LDP and RSVP-TE for Optical Path Set-up
draft-fan-mpls-lambda-signaling-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 [1].
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
Real-time optical path setup is a fundamental requirement for agile
optical networks and signaling is a mechanism to achieve automatic
fast path setup. Our objective is to define extensions to both CR-
LDP and RSVP-TE that address this requirement. CR-LDP and RSVP-TE
1
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
are defined in [CR-LDP] and [RSVP], respectively, for path setup
within a MPLS domain. In this draft, we specify mechanisms, TLVs and
Objects required to support Optical Label Switched Path setup.
Table of Contents
1. Introduction
2. Agile Optical Network Overview
2.1 Compatibility Check
2.2 Optical User-Network Interface Check
2.3 Optical Information Distribution
2.4 Composite Labels
3. Extensions to CR-LDP
3.1 Messages and TLVs that are affected by the extensions
3.1.1 Initialization Message
3.1.2 Label Request Message
3.1.3 Label Mapping Message
3.1.4 Notification Message
3.1.5 Release, Withdraw and Abort Messages
3.2 Optical TLV Extensions
3.2.1 Optical Session Parameters TLV
3.2.2 Optical Interface Type TLV
3.2.2.1 Service Type Mask
3.2.2.2 Control Protocol Mask
3.2.3 Optical Trail Descriptor TLV
3.2.4 Optical Label TLV
3.2.5 Lambda Set TLV
4. Extensions to RSVP-TE
4.1 Messages and Objects that are affected by the extensions
4.1.1 Path Message
4.1.2 Resv Message
4.1.3 PathErr and ResvErr Messages
4.2 Optical Object Extensions
4.2.1 Optical Label Request Object
4.2.2 Optical Interface Type Object
4.2.3 Optical Trail Descriptor Object
4.2.4 Optical Label Object
4.2.5 Lambda Set Object
5. Processing of Optical TLVs and Optical Objects
5.1 Processing of Optical Session Parameters TLV/Optical Label
Request Object
5.2 Processing of Optical Interface Type TLV/Object
5.3 Processing of Optical Trail Descriptor TLV/Object
5.4 Processing of Optical Label TLV/Object
5.5 Processing of Lambda Set TLV/Object
5.6 Error codes
6. Security Considerations
7. References
8. Acknowledgements
9. Authors' Addresses
Appendix A
Fan et al. Expires September 2000 2
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
1. Introduction
There has been an increasing interest recently in agile optical
networks. Agility in optical networks implies fast end-to-end
optical path setup and restoration. One way to set up an optical
path through an agile optical network quickly is to use signaling
together with dynamic routing. Routing is used to collect
information on network topology and resources, pass states around
and compute the optimal paths from one node to the others.
Signaling is used to setup, maintain, modify/renegotiate and tear
down these paths.
CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP], respectively.
They both support constraint-based routed label switched paths.
Therefore, it is natural to extend them to set up optical paths in
an agile optical network.
The extensions defined in this draft provide support for Optical
Label Switched Path (OLSP) setup, maintenance, and teardown in
optical networks by introducing five new types of TLVs/Objects and
procedures related to CR-LDP/RSVP-TE.
2. Agile Optical Network Overview
An optical MPLS-enabled network consists of Optical Label Switching
Routers (OLSR) and point-to-point links. The OLSRs are
interconnected by links in a mesh topology. There are two types of
interfaces in this network: Optical Node-to-Node Interface (ONNI)
between two OLSRs and Optical User-Network Interface (OUNI) between
customer premise equipment (CPE) and OLSRs. The signaling protocol
defined in this draft may serve as part of both ONNI and OUNI. An
agile MPLS-enabled optical network is an optical network with fast
OLSP setup and restoration. In this network, the control component
of an OLSR consists of a routing protocol (OSPF or IS-IS, for
example) and a signaling protocol (CR-LDP or RSVP-TE, for example).
All control information can be exchanged through dedicated control
channels or independent signaling networks as discussed in [Sigarch]
and [OLXC]. The means to accomplish this is for further study.
An OLSR can be anyone of the following types of optical cross-
connects equipped with the control component described above:
1. Switching at fiber level
2. Cross-connect at Lambda level only
3. Cross-connect at sub-Lambda level only (for an example, SONET/SDH
DXCs, etc.)
4. Cross-connect at both Lambda and sub-Lambda levels
An OLSR can be a Lambda conversion-capable (CC) OLSR or a Lambda
conversion-incapable (CI) OLSR. A CC-OLSR is an OLSR that is capable
of cross connecting between any wavelengths, and a CI-OLSR is one
Fan et al. Expires September 2000 3
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
that can only cross-connect the same wavelength between different
interfaces.
There are two types of links, service-transparent (ST) links and
service-aware (SA) links. A ST-link is a link providing transparent
bit transmission, and the interfaces on both ends of this link
simply perform bitwise input and output operation. An ST-Link can
accept data at any bit rate below a certain maximum bit rate and any
protocol format. A pure optical link in which the signal remains in
optical form from the link input interface to the link output
interface is an example of a ST-link. An SA-link is a link in which
interfaces on both ends will handle the payload according to
protocol format and/or data bit rate before transmitting and after
receiving. An OC-192 link is an example of a SA-link.
In an MPLS-enabled optical network, an LSP is an optical path
between two OUNIs. An LSP may consist of a fiber bundle, just single
fiber, the concatenation of multiple Lambdas, just one Lambda,
groups of sub-Lambda channels, or just one sub-Lambda. The label in
an MPLS-enabled agile optical network may represent any of the
following:
1. A fiber bundle
2. An arbitrary number of fibers in that bundle
3. A single fiber
4. An arbitrary number of Lambdas within a fiber
5. A single Lambda
6. An arbitrary number of sub-Lambda channels
7. A single sub-Lambda channel
In the proposal described in [Lambda], a Lambda is the granularity
of an OLSP. We believe that Lambda granularity is too coarse for a
number of reasons:
1) Bandwidth management and allocation is one issue. We may have,
for example, an OC-48 encoding Lambda coming into an OLSR and OC-192
encoding Lambda going out of this OLSR. If our allocation
granularity is only at the Lambda level, we must map the OC-48 to an
entire OC-192 pipe and, therefore, we waste three quarters of the
bandwidth.
2) Scalability is another issue. Many routers are interconnected
through an optical network, which requires a lot of optical paths
among them. We may have a similar "n squared" problem that classical
IP over ATM has because we don't want the traffic to cross the
optical network twice even we can have the direct optical path
between the source and destination. We may quickly run out of
Lambdas if these optical paths are Lambda paths, as opposed to sub-
Lambda paths. The development of Lambda merging technology may
alleviate this problem. However, this type of technology is not
available yet. In this draft the granularity of OPLS can be multiple
fibers, a single fiber, multiple Lambdas, a single Lambda, different
Fan et al. Expires September 2000 4
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
levels of sub-Lambdas, and groups at all fiber, Lambda and sub-
Lambda levels.
The Optical Trail Descriptor (OTD) contains the attributes of an
optical trail. OTD defines the service type and the channel group.
The service type can be SONET, Ethernet, etc. The Channel group can
be a Lambda group, an OC-48 group, etc. The Optical Interface Type
(OIT) defines the OUNI types. When an OLSP Request is generated, the
OTD and requested OIT of OUNI interface of the egress OLSR must be
specified.
2.1 Compatibility Check
To set up an OLSP in agile optical networks, we must make sure that
all links crossed by the OLSP are compatible with the OTD. The
compatibility check must be performed at each SA-link. A new type of
TLV/Object, OTD TLV/Object is defined to encode the OTD information.
ST or SA information is the property of links. The routing protocol
will carry this information. When ER-LSPs are calculated, this
information will be taken into consideration.
2.2 Optical User-Network Interface Check
To set up an OLSP in agile optical networks, we must make sure that
both the input interface of the ingress OLSR and the output
interface of the egress OLSR have the same type of OUNI. The OUNI
check must be performed at the egress OLSR or at both the Ingress
and the Egress OLSRs. A new type of TLV/Object, the OIT TLV/Object,
is defined to encode the OIT information.
A routing protocol may carry optical interface information about
particular OUNI, and may take this information into account when
computing paths for optical trails.
2.3 Optical Information Distribution
In order to propagate optical state information and calculate the
available paths, extensions to OSPF/IS-IS are defined in [ROUTING].
The Optical LSA/LSP extension advertises the available resource
information. This extension is an opaque LSA/LSP.
2.4 Composite Labels
The signaling protocols for MPLS explicitly routed LSPs use a label
which is passed backwards from destination to source to construct
the actual data-path. As each label is received for a particular
output, a new label is allocated for the corresponding input. Thus
the switching from input label/interface to output label/interface
is programmed. To accommodate the switching of entire fibers,
Lambdas within those fibers and sub-Lambdas, we introduce the
concept of a composite label. This composite label allows the
Fan et al. Expires September 2000 5
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
signaling protocol to establish entire fiber/Lambda and/or sub-
Lambda paths using a single end to end mapping/resv message without
having to run recursive instances of the signaling protocol.
Composite labels do not however preclude the use of recursive
signaling instances should this prove necessary for administrative
or scalability reasons. One important effect of a composite label is
that sub-Lambdas may result in the allocation of new Lambda, which
may in turn result in the allocation of entire fibers.
A composite label has a somewhat complex TLV format, so as an aid to
understanding them we introduce the following ASCII representation
for a composite label:
{ <Fiber>*.<Lambda>*.<Sub-Lambda>* }*
Composite labels travel within a mapping/resv message and behave in
a manner similar to normal shim or other in-band labels. This means
that a mapping/resv message can control the switching of an entire
fiber on some input bundle to an entire fiber on some output bundle,
an entire Lambda to a corresponding Lambda, or a sub-Lambda to sub-
Lambda. Many other mapping/sub-mapping combinations exist, and what
is legal is dictated by what is supported by the switching hardware
being traversed.
Example: The receipt of mapping/resv with the label F7.*.* may cause
the generation of a mapping/resv with the label F4.*.*. The result
would be that fiber 4 on the input bundle would be mapped entirely
to fiber 7 on the output bundle.
Example: The receipt of mapping/resv with the label F7.L4.* may
cause the generation of a mapping/resv with the label F4.L62.*. The
result would be that the fiber 4, Lambda 62 would be mapped
completely to fiber 7 Lambda 4 on the output port.
Example: The receipt of mapping/resv with the label F1.L1.{0-2} may
cause the generation of mapping/resv with the label F3.L2.{4-6}. The
result would be that fiber 3 Lambda 2, timeslots 4,5,6 would be
mapped to fiber 1, Lambda 1, timeslots 0, 1 and 2 on the output
port.
Example: The receipt of mapping/resv with the label F1.{L1,L2}.* may
cause the generation of mapping/resv with the label F3.{L7,L9}.*.
The result would be that fiber 3, Lambdas 7 and 9 would be mapped
into fiber 1, Lambdas 1 and 2 respectively on the output port.
There are numerous other combinations, limited only by the electro-
optical transformations that can be done by any specific switch.
Example: The receipt of a mapping/resv with the label
F1.L1.{0-47,48-95,96-143,144-191} may cause the generation of a
mapping/resv with the label {F2.L4.0-47, F2.L5.0-47, F2.L6.0-47,
F2.L7.0-47}. The result is that 48 timeslots on four Lambdas 4,5,6
Fan et al. Expires September 2000 6
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
and 7 on fiber 2, would be mapped into all 192 timeslots on the
output fiber 1, on Lambda 1. The inverse of this example is also
possible. So a composite label with 4 Lambdas and timeslots when
received, may result in the generation of a single Lambda and
timeslot set. This represents an inverse multiplexing capability by
the switch being traversed.
The Appendix of this document shows some examples of the actual
formats for some different ASCII representations of composite
labels.
3. Extensions to CR-LDP
3.1 Messages and TLVs that are affected by the extensions
Any messages, TLVs, and procedures not defined explicitly in this
document are defined in [LDP] or [CR-LDP].
The following subsections serve as a cross-reference to [LDP] and
[CR-LDP] and as an indication of additional functionality beyond
what is defined in [LDP] and [CR-LDP]. "Optional" in the following
text is relative to [LDP] or [CR-LDP]. The TLV has to be used if
specified here.
3.1.1 Initialization Message
The Initialization message is as defined in Section 3.5.3 of [LDP]
and is exchanged during LDP peer session initialization to agree
upon the common set of parameters to be used when setting up LSPs.
The message is used by OLSRs during the initialization with the
following extensions:
- The Optical Session Parameters TLV must be used as an optional TLV
- The procedures to handle Initialization message are augmented by
the procedures for processing of the Optical Session Parameters TLV
as defined in Section 4
3.1.2 Label Request Message
The Label Request message is as defined in Section 3.5.8 of [LDP]
and Section 3.2 of [CR-LDP] and used for setting up OLSPs with the
following extensions:
- The OIT TLV must be used as an optional TLV
- The OTD TLV must be used as an optional TLV
- Lambda Set TLV is an optional TLV
- The procedures to handle the Label Request message are augmented
by the procedures for processing of the OIT, OTD and Lambda Set TLVs
as defined in Section 5
3.1.3 Label Mapping Message
Fan et al. Expires September 2000 7
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
The Label Mapping message is as defined in Section 3.5.7 of [LDP]
and Section 3.3 of [CR-LDP] and used for setting up OLSPs with the
following extensions:
- The Optical Label TLV must be used as the Label TLV.
- The Label Mapping procedures are limited to downstream on demand
ordered control mode with conservative label retention mode.
- The procedures to handle the Label Mapping message are augmented
by the procedures for processing of the Optical Label TLV as defined
in Section 5.
3.1.4 Notification Message
The Notification message is as defined in Section 3.5.1 of [LDP] and
Section 3.3 of [CR-LDP]. The Status TLV encoding is as defined in
Section 3.4.7 of [LDP]. New status codes are defined in Section 5.6
to signal error notifications associated with the establishment of
an OLSP and the processing of the Optical-TLVs. The Notification
message may also carry an OIT or OTD TLV. When the OUNI check or
compatibility check fails, the ingress OLSR can updates its database
correctly by taking into account the actual OUNI type or the link
attributes contained in the OIT or OTD TLV.
3.1.5 Release, Withdraw and Abort Messages
The Label Release, Label Withdraw and Label Abort messages are used
as specified in [LDP] to clear OLSPs. These messages may also carry
the Optical Label TLV.
3.2 Optical TLV extensions
The messages defined in [LDP] and [CR-LDP] optionally carry one or
more of the optional Optical TLVs defined in this section. In this
specification, the following TLVs are defined:
- Optical Session Parameters TLV
- Optical Interface Type TLV
- Optical Trail Descriptor TLV
- Optical Label TLV
- Lambda Set TLV
3.2.1 Optical Session Parameters TLV
The Optical Session Parameters TLV is used when an LDP session
manages label exchange for Optical Link to specify Optics-specific
session parameters.
Fan et al. Expires September 2000 8
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Optical Sess Parms | Length |
| | | (0x0503) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Label Range Component 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M is a 3-bit field that specifies the Multiplexing Capabilities of
an OLSR. The following values are supported in this version:
Value Meaning
----- ----------------------------------
0 Multiplexing not supported
1 SONET/SDH multiplexing supported
2 others (e.g., GE multiplexing supported)
N is a 4-bit field that specifies the number of optical label range
components.
The encoding for an Optical Label Range Component 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Lambda ID | Minimum Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fiber ID is a 16-bit field that identifies one fiber.
Maximum Lambda ID is a 16-bit field that specifies the lower bound
of a block of Lambdas that are supported by the originating OLSR.
Minimum Lambda ID is a 16-bit field that specifies the lower bound
of a block of Lambdas that are supported by the originating OLSR.
3.2.2 Optical Interface Type TLV
Fan et al. Expires September 2000 9
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
The OIT TLV is used to represent the traffic characteristics of a
User-Network interface. It is carried by Request message. The OIT
TLV encoding is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|1| Optical Interface Type | Length |
| | | (0x0910) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit refers to Unknown TLV bit as defined in [LDP].
Length specifies the length of the value field in bytes.
3.2.2.1 Service Type Mask
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the length of the value field in bytes.
Service Type ID identifies each service type by a unique 32-bit
number. The following numbers are defined in this version:
Service
Type ID Description
--------- -------------
0 IP
1 ATM
2 Frame Relay
3 SONET
4 GE
5 FDDI
Fan et al. Expires September 2000 10
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
3.2.2.2 Control Protocol Mask
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Protocol ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Protocol ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Protocol ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the length of the value field in bytes.
Control Protocol identifies each control protocol by a unique 32-bit
number. The following numbers are defined in this version:
Protocol
Type ID Description
--------- -------------
0 OSPF
1 RIP
2 BGP4
3 EGP
4 MOSPF
5 DVMRP
6 PIM
7 IS-IS
8 PNNI
3.2.3 Optical Trail Descriptor TLV
The OTD TLV represents the characteristics of an optical trail. The
optical trail may consist of one or more channel groups of different
granularity. All members within a group must have the same
granularity, but different group types may be mixed into one OTD
TLV. OTD TLV is carried by Request message and its encoding is as
follows:
Fan et al. Expires September 2000 11
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Optical Trail Desc | Length |
| | | (0x0920) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the length of the value field in bytes.
Channel Group describes the components of an optical trail. The
encoding of the Channel Group 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group Type | Number of Group Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Channel Group Type defined in this version is as follows:
Channel
Group
Type Description
--------- -------------
1 Fiber
2 Lambda
3 GE
4 10 GE
5 OC-3/STM-1
6 OC-3c
7 OC-12/STM-4
8 OC-12c
9 OC-48/STM16
10 OC-48c
11 OC-192/STM-64
12 OC-192c
13 OC-768/STM-256
14 OC-768c
Fan et al. Expires September 2000 12
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Number of Group Members specifies the number of members within the
group.
3.2.4 Optical Label TLV
Optical Label TLVs encode optical labels. A simple composite optical
Label, noted as F.L.S, is described in 2.4 and is encoded here. The
multiple F.L.S can be used to compose an optical Label representing
one or more channel groups of different granularity. Optical Label
TLVs are carried by the messages used to advertise, request, release
and withdraw label mappings.
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 (0x0930) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Component 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Component n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit refers to Unknown TLV bit as defined in [LDP].
F bit refers to Forward unknown TLV bit as defined in [LDP].
Length specifies the length of the value field in bytes.
Label Component encodes F.L.S for a channel group and is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group Type | Number of Group Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Line Rate Encoding Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Channel Group Type is defined in 3.2.3.
Number of Group Member is defined in 3.2.3.
Line Rate Encoding Type specifies the top encoding protocol.
Examples of encoding type include SONET (OC-192, OC-48, etc.) and
Fan et al. Expires September 2000 13
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Ethernet (GE and 10 GE). The type value is the same as channel group
type, plus one more, the transparent bit service. The transparent
bit service type value is 0.
Length specifies the length of field following this field in bytes.
Fiber ID is a 16-bit field to specify the fiber.
The Lambda ID is a 16-bit field that identifies a Lambda. All the
Lambda IDs will be 0x0000 if the group type is fiber. Both Fiber ID
and Lambda ID have to be consistent between the two peers. The means
to achieve this is out of the scope of this document.
Channel Group ID specifies one channel group and is aligned with 4-
octet boundary and the format depends on Channel Group Type. The
content of the Channel Group ID depends on the channel group type.
The Channel Group ID is as follows:
1) For fiber and Lambda group types
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2) For SONET/SDH group type
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel ID consists of all STS-1s/STM-1s identified in the bit
Mask. The 0 bit in the first 4-octet corresponds to the first STS-
1/STM-1. If group ID bit masks in the last 4-octet are less than 32-
bits, it should be left justified in this field and succeeding bits
should be set to 0. If the encoding type is OC-192, for example, the
group type is OC-48 and the one member in this group, then the
Channel ID is 24 bytes long with only 48 bits being set. See
appendix A for more details.
3.2.5 Lambda Set TLV
Fan et al. Expires September 2000 14
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Lambda Set TLV represents the set of current available Lambdas. It
is useful when trying to setup OLSP through CI-OLSR(s). This TLV is
carried by Request message and encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Lambda Set (0x0940) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit refers to Unknown TLV bit as defined in [LDP].
F bit refers to Forward unknown TLV bit as defined in [LDP].
Length specifies the length of the value field in bytes.
Lambda ID is defined in 3.2.4.
4. Extensions to RSVP-TE
4.1 Messages and Objects Affected by the Extensions
Any messages, objects, and procedures not defined explicitly in this
document are defined in the [RSVP] Specifications.
The following subsections serve cross-reference to the [RSVP]
documents and indicate of additional functionality beyond what is
defined in [RSVP]. "Optional" in the following text is relative to
[RSVP]. If defined in this specification the TLV has to be used.
4.1.1 Path Message
The Path message is as defined in Section 3.1 of [RSVP] and with the
following extensions:
- The optical label request object must be used as an optional
object.
- The optical trail descriptor object must be used as an optical
object.
- The optical interface type object must be used as an optical
object.
- Lambda object is an optional object.
- The procedures to handle the Path message are augmented by the
procedures for processing of optical label request, OIT, OTD and
Lambda set objects as defined in Section 5.
Fan et al. Expires September 2000 15
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<OPTICAL LABEL_REQUEST>
<OPTICAL TRAIL DESCRIPTOR>
<OPTICAL INTERFACE TYPE>
[ <LAMBDA SET> ]
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
4.1.2 Resv Message
The Resv message is as defined in Section 3.2 of [RSVP] and with the
following extensions:
- The optical label must be used as an optional object.
- The procedures to handle the Resv message are augmented by the
procedure for the processing of optical label objects as defined
in Section 5.
The format of Resv message is the same as that in Section 3.2 of
[RSVP] except for the replacement the LABEL object with the
OPTICAL_LABEL object.
4.1.3 PathErr and ResvErr Messages
The PathErr and ResvErr message may also carry optical objects.
4.2 Optical Object Extensions
The messages defined in [RSVP] optically carry one or more of the
optical objects defined in this section. In this specification, the
following optical objects are defined:
- OPTICAL_LABEL_REQUEST object
- OPTICAL_TRAIL_DESCRIPTOR object
- OPTICAL_INTERFACE_TYPE object
- OPTICAL_LABEL object
- LAMBDA_SET object
Fan et al. Expires September 2000 16
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
4.2.1 Optical Label Request Object
The OPTICAL_LABEL_REQUEST object is carried in the Path message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=19 | C-Type = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Label Range Component 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Label Range Component n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the object length in bytes.
Reserved is a reserved field. It MUST be set to zero on transmission
and MUST be ignored on receipt.
L3PID identifies the layer 3 protocol using this path. Standard
Ethertype values are used.
Optical Label Range Component is defined in Section 3.2.1.
4.2.2 Optical Interface Type
This OPTICAL_INTERFACE_TYPE object is carried in the Path message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=19 | C-Type = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-objects |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the object length in bytes.
Fan et al. Expires September 2000 17
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Sub-objects Are Service Type TLV and Control Protocol TLV defined
in Section 3.2.2.1 and 3.2.2.2.
4.2.3 Optical Trail Descriptor Object
The OPTICAL_TRAIL_DESCRIPTOR object is carried in the Path message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=19 | C-Type = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Group n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the object length in bytes.
Channel Group is defined in Section 3.2.3.
4.2.4 Optical Label Object
This OPTICAL_LABEL object is carried in the Resv message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=19 | C-Type = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Component 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Component n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the object length in bytes.
Label Component is defined in Section 3.2.4.
Fan et al. Expires September 2000 18
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
4.2.5 Lambda Set Object
This LAMBDA_SET object is carried in the Path message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=19 | C-Type = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length specifies the object length in bytes.
Lambda ID is defined in Section 3.2.4
5 Processing of Optical TLVs and Optical Objects
5.1 Processing of Optical Session Parameters TLV/Optical Label Request
Object
A receiving OLSR MUST calculate the intersection between the
received range and its own support range. The intersection is the
range in which the OLSR may allocate and accept labels. If the
intersection of ranges is NULL, the OLSR must send a Notification
message with the error code "Session Rejected/Parameters Label
Range" in response to the Initialization message and not establish
the session in CR-LDP case, or should send a PathErr message with
the error code "Routing problem" and the error value "MPLS label
allocation failure" in RSVP case.
5.2 Processing of Optical Interface Type TLV/Object
When an edge OLSR receives a Request or Path message, it retrieves
the OIT field from the message and compares the value of every
attribute with that of the requested user-network interface. If all
the attributes match, the OIT check is successful. Otherwise, this
OLSR generates a Notification or PathErr message to indicate the
mismatch. The error code is defined in Section 5.6.
For the tandem OLSR, the OIT TLV or Object remains untouched.
5.3 Processing of Optical Trail Descriptor TLV/Object
Fan et al. Expires September 2000 19
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
When an OLSR receives a Request or Path message over a SA-link, it
retrieves the OTD field from the message and assigns a Label based
on the OTD field. When an OLSR sends a Request or Path to next hop
over a SA-link, it performs the compatibility check first. The
Request or Path message is sent out if the check is successful.
Otherwise, this OLSR generates a Notification or PathErr message to
indicate the compatibility check failure. The Error code is defined
in Section 5.6.
The compatibility check must be performed at each SA-link to make
sure this link can support the certain type of optical trail as
requested. A requested optical trail for example, could be an OC-48
trail and may be built over an OC-192 link. The compatibility check
will be successful if this link can support OC-48 multiplexing and
an OC-48 channel is available. Otherwise, the compatibility check
will fail.
The label is assigned based on the OTD field when Mapping or Resv
message is handled.
5.4 Processing of Optical Label TLV/Object
The processing of Optical Label TLV or Object is similar to that of
non-optical label TLV or Object. When an OLSR receives an Optical
Label TLV or Object from the Mapping or Resv message, the OLSR
updates its Label Information Table with the new label and also
configures its connection table based on the Label.
5.5 Processing of Lambda Set TLV/Object
When a CI-OLSR receives a Request or Path message and checks the
existence of Lambda Set TLV or Object. If the Request or Path
message contains a Lambda Set TLV or Object, this CI-OLSR calculates
the intersection between the received Lambda set and its own
available Lambda set, and replace the Lambda Set TLV or Object field
by the intersection Lambda set if the intersection is not NULL.
Otherwise, this CI-OLSR generates a Notification or PathErr message
to indicate NULL intersection. If the Request or Path message
doesn't have a Lambda Set TLV or Object, this CI-OLSR adds a Lambda
Set TLV or Object with its own available Lambda set.
When a CC-OLSR receives a Request or Path message and removes the
Lambda Set TLV or Object if there is one. This CC-OLSR can assign a
Label for this OLSP only from the Lambda set contained in Lambda Set
TLV or Object.
5.6 Error codes
In the Optical-TLV and Optical-Object processing described above,
certain errors need to be reported as part of the Notification,
PathErr or ResvErr Message. This section defines the status codes
Fan et al. Expires September 2000 20
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
for the errors described in this specification. At present, these
codes are not exhaustive.
Status Code Type
--------------------------- ------------
Interface OIT Mismatch 0x05000001
Compatibility Check Failure 0x05000002
Bad OIT TLV/Object 0x05000003
Bad OTD TLV/Object 0x05000004
Bad Optical Label TLV/Object 0x05000005
Bad Lambda Set TLV/Object 0x05000006
NULL intersection 0x05000007
6. Security Considerations
This draft does not introduce any new security considerations beyond
those specified in [LDP], [CR-LDP], and [RSVP].
7. References
[LDP] Andersson, et al, "Label Distribution Protocol Specification,"
draft-ietf-mpls-ldp-06.txt, Work in progress, October 1999.
[CR-LDP] Bilel Jamoussi, "Constraint-Based LSP Setup using LDP,"
draft-ietf-mpls-cr-ldp-03.txt, Work in progress, September 1999.
[RSVP] Awduche, et al, "Extensions to RSVP for LSR Tunnels," draft-
ietf-mpls-rsvp-lsp-tunnel-04.txt, Work in progress, September 1999
[Lambda] Awduche, et al, "Multi-Protocol Lambda Switching: Combining
MPLS Traffic Engineering Control with Optical Crossconnects," draft-
awduche-mpls-te-optical-01.txt, Work in progress, November 1999
[ROUTING] Wang, et al, "Extensions to OSPF/IS-IS for Optical
Routing," draft-wang-ospf-isis-lambda-te-routing-00.txt, Work in
progress, March 2000
[PAR] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0,"
AF-RA-0104.000, January 1999
[AOTN] Draft ITU-T Recommendation G.872, "Architecture of Optical
Transport Networks," April 1999.
[Sigarch] M. Krishnaswamy, et.al., "MPLS Control Plane for Switched
Optical Networks", draft-krishmaswamy-mpls-son-00.txt, work in
progress, March 2000
Fan et al. Expires September 2000 21
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
[OLXC] Sid Chaudhuri, Gisli Hjalmtysson, Jennifer Yates, "Control of
Lightpaths in an Optical Network", draft-chaudhuri-ip-olxc-control-
00.txt, work in progress, February 2000
8. Acknowledgments
The authors would like to thank Guoqiang Wang, Loa Andersson, Bilel
Jamoussi and Stephen Shew for their comments on the draft.
9. Author's Addresses
Yanhe Fan Peter Ashwood-Smith
Nortel Networks Nortel Networks
PO Box 3511 Station C PO Box 3511 Station C
Ottawa, ON, K1Y 4H7 Ottawa, ON, K1Y 4H7
Canada Canada
Phone: 613-765-2315 Phone: 613-763-4534
yanhe@nortelnetworks.com petera@nortelnetworks.com
Vishal Sharma Ken Owens
Tellabs Research Center Tellabs Operations, Inc.
One Kendall Square 1106 Fourth Street
Bldg. 100, Suite 121 St. Louis, MO 63126
Cambridge, MA 02139 USA
USA Ph: 314-918-1579
Ph: 617-577-8760 Ken.Owens@tellabs.com
vishal.sharma@tellabs.com
Gerald R. (Jerry) Ash Murali Krishnaswamy
AT&T Labs Lucent Technologies
Room MT E3-3C37 3C-512
200 Laurel Avenue 101 Crawfords Corner Rd.
Middletown, NJ 07748 Holmdel NJ 07733
USA USA
Phone: 732-420-4578 Voice: +1 732 949 3611
Fax: 732-440-6687
gash@att.com murali@lucent.com
Yang Cao M. K. Girish
Lucent Technologies SBC Technology Resources, Inc.
21-2A33, 1600 Osgood St 4698 Willow Road,
North Andover, MA 01845-1043 Pleasanton, CA 94588
USA USA
Phone: +1 978 960 6173 Phone: +1 925 598-1263
Fax: +1 978 960 6329 Fax: +1 925 598-1322
yangcao@lucent.com mgirish@tri.sbc.com
Fan et al. Expires September 2000 22
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Dr. Simon Bernstein Phuc Nguyen
Global One Global One
12490 Sunrise Valley Drive 12490 Sunrise Valley Drive
Reston, Reston,
VA 20196-0001 USA VA 20196-0001 USA
Phone: +1 703 689-7109 Phone: +1 703 689-7870
Fax: + 1 703 689-6724 Fax: + 1 703 689-6724
simon.bernstein@globalone.net Phuc.Nguyen@GlobalOne.net
Herbert M. Ruck Lihshin Wang
Packet Network Services Qwest Communication.
NEC America, Inc. 4250 N Fairfax Drive
1525 Walnut Hill Lane Arlington, VA
Irving, TX, 75038 USA
U.S.A. Phone: 703-363-3986
Tel. 972-518-3590 Lihshin.Wang@qwest.com
ruck@asl.dl.nec.com
Sunil Ahluwalia Hans Sjostrand
Trillium Digital Systems Inc, Ericsson
12100 Wilshire Blvd. #1800 Business Unit Datacom Networks
and IP Services
Los Angeles, CA 90025 S-126 25 Stockholm,
USA Sweden
Phone: 310 442 9222 Phone: +46 8 719 9960
sunil@trillium.com hans.sjostrand@etx.ericsson.se
Klas Eriksson Heinrich Hummel
Utfors AB Siemens AG
Svetsarvagen 24 Hofmannstrasse 51
Sweden 81379 Munich, Germany
tel: +46 8 52 70 30 05 Tel: +49 89 722 32057
klas.eriksson@utfors.se heinrich.hummel@icn.siemens.de
Avri Doria
Nokia Telecommunications
3 Burlington Woods Drive,
Suite 250,Burlington, MA 01803
Phone: +1 781 359 5131
Mobile: +1 617 678 9402
avri.doria@nokia.com
Fan et al. Expires September 2000 23
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Appendix A
This appendix gives more examples of the optical label.
1) F.<L1, L2>.*
This is for an optical trail of a Lambda group with no sub-Lambda
groups.
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| 0x0930 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fan et al. Expires September 2000 24
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
2) F.L.<S1, S2>
This is for an optical trail of two sub-Lambda groups (one OC-48
group with two members and one OC-12 group with one member).
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| 0x0930 | 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- Channel ID 1 +-+-+-+
| |
+-+-+-+- . . . +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber ID | Lambda ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+- Channel ID 2 +-+-+-+
| |
+-+-+-+- . . . +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Channel ID 1 is 192-bits long and with 96 bits being set. The
Channel ID 2 is 192-bits long with only 12 bits being set. Each bit
represents an STS-1.
Fan et al. Expires September 2000 25
Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Fan et al. Expires September 2000 26