MPLS Working Group Osama Aboul-Magd
Internet Draft Nortel Networks
draft-ietf-mpls-ldp-optical-uni-00.txt Raj Jain
Expiration Date: April 2001 Nayna Networks
LiangYu Jia
ONI Systems
Bala Rajagopalan
Tellium
Robert Rennison
Laurel Networks
Yangguang Xu
Lucent Tech
Zhensheng Zhang
Sorrento Networks
October, 2000
LDP Extensions for Optical User Network Interface (O-UNI) Signaling
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.
1. Abstract
General requirements for signaling across the Optical UNI (O-UNI) are
discussed in [1]. This draft describes extensions to the LDP protocol
[2] to support those requirements. The LDP extensions described here
address two areas:
- The addition of new TLVs to support the attributes required for
lightpath establishment at the O-UNI
Aboul-Magd April 2001 1
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
- Two new LDP messages to allow for the exchange of lightpath status
information across the UNI.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].
3. Use of LDP for the O-UNI
This draft describes how LDP with extensions will be used as a
signaling mechanism for the O-UNI. Several O-UNI abstract messages are
defined in [1]. This draft specifies how to use the existing LDP
messages for that purpose. Two new LDP messages are introduced to meet
the requirements for the exchange of status information across the O-
UNI.
3.1. Overview
LDP is one of the candidate protocols described in [1] for O-UNI
signaling implementation.
Applying LDP at the O-UNI allows for:
- The reuse of already defined LDP messages and message formats
- The reuse of LDP session management and control procedures
- Additions to the already specified procedures for notification of
errors.
- The reuse of the LDP security mechanism
Support for the O-UNI signaling requirements depends upon the use of
the following LDP behaviors and mechanisms as defined in [2].
- Use of Basic and/or Extended discovery mechanisms.
- Use of the Label Request Message in downstream on demand label
advertisement mode with ordered control.
- Use of the Label Mapping Message in downstream on demand label
advertisement mode with ordered control.
- Use of the Notification Message.
- Use of the Withdraw and Release Messages.
Additional messages are defined to support the propagation of lightpath
status information as defined in [1].
Additional TLVs are specified to support the lightpath attributes
specified in [1].
Aboul-Magd April 2001 2
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
4. O-UNI Session Management and Control
LDP messages that relevant to the O-UNI session management and control
are Hello Message, Initialization Message, and KeepAlive Message.
4.1. Hello Message
This draft does not change the format or the procedures of the LDP
Hello Message as described in section 3.5.2. of [2].
4.2. KeepAlive Message
This draft does not change the format or the procedures of the LDP
KeepAlive Message as defined in section 3.5.4 of [2].
4.3. Initialization Message
The Initilaization Message is as defined in section 3.5.3 of [2] with
the following modifications:
- The Label Advertisement Discipline (the ôAö bit) is always set at 1
to indicate Downstream on Demand label distribution mode. Downstream on
Demand is the only label distribution mode supported at the O-UNI. The
assignment A=0 should result in generating a Notification Message with
the appropriate error code.
- Loop Detection is always disabled, D=0. The assignment D=1 should
result in generating a Notification Message with the appropriate error
code.
5. The Use of LDP Messages for O-UNI
A set of abstract O-UNI messages is defined in [1]. Those abstract
messages support the basic functions of the optical UNI. Those
functions are,
- Lightpath Create: Creates a lightpath with certain attributes between
two ends in the optical networks
- Lightpath Delete: Deletes an already existing lightpath
- Lightpath Modify: Modifies one or more of the attributes of already
existing lightpath
- Lightpath Status Enquiry: Enquires about the status of an already
existing lightpath
Each of the above functions is accomplished by a set of O-UNI messages
using LDP protocol.The procedures for handling LDP messages across the
optical UNI are augmented to add the additional O-UNI functionality.
Common across the O-UNI are:
Aboul-Magd April 2001 3
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
- The LDP FEC TLV should be ignored at the O-UNI since it has no
significance, and
- The use of LDP messages for O-UNI does not change the semantics of
the LDP Message ID.
5.1. Lightpath Create Action
Lightpath Create Action requires two messages, the lightpath Create
Request and the Lightpath Create Response. The mapping of the LDP
messages to fulfill the lightpath create action is:
- Lightpath Create Request: The create request function is achieved by
the LDP Label Request Message. The Generalized Label Request TLV
defined in [4] is used to convey some lightpath attributes to the
network side.
- Lightpath Create Response: The create response function is achieved
by the use of the LDP Label Mapping Message. The create response
function makes use of the Generalized label defined in [4]. The Label
Mapping procedures are limited to downstream on demand, ordered control
mode with conservative label retention mode.
5.2. Lightpath Delete Action
Lightpath Delete Action requires two messages,
the Lightpath Delete Request and the Lightpath Delete Response. The
mapping of the LDP messages to fulfill the function of the lightpath
delete action is:
- Lightpath Delete Request: The delete request is achieved by the LDP
Label Release Request Message. The Label Release Message is sent from
the client or the network at any time after the establishment of the
lightpath to delete it.
- Lightpath Delete Response: The delete Response is achieved by the LDP
Label Withdraw Message. The Label Withdraw Message is sent from the
client or the network in response to a Label Release Request.
5.3. Lightpath Modify Action
After a lightpath is setup, some of its attributes, e.g. bandwidth, may
need to be changed by the network operator due to new requiremenst for
the traffic carried on that lightpath. Lightpath Modify Action does not
require the definition of new LDP messages. The modify action follows
the procedure described in [5].
Lightpath modification can only be allowed when the lightpath is
already established. The procedure described in [5] allows for
modification of lightpath attributes without service interruption. Only
modifications requested by the owner of a particular lightpath are
allowed.
Aboul-Magd April 2001 4
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The procedure described in [5] for lightpath modification relies on the
introduction of the Action Flag (ActFlg) field in the Lightpath Id TLV
(see section 6.1.3). Similar to the case in CR-LDP [7], the ActFlg
field indicates if the signaled Lightpath Request is an initial
lightpath setup or a modification request.
5.4. Lightpath Status Action
Lightpath Status Actionrequires two messages, Lightpath Status Enquiry
and Lightpath Status Response
The Lightpath Status Enquiry and Lightpath Status Response functions
require the definition of two new LDP messages, The Status Enquiry
Message and the Status Response Message. The encoding of the new
messages is defined in sections 6.6 and 6.7.
5.5. Notification Action
The Notification function is similar in scope to that of the CR-LDP
Notification Message. Hence the LDP Notification message is used across
the O-UNI for this purpose.
6. LDP Message Extensions
This section gives detailed description of LDP message extensions for
the support of O-UNI.
6.1. Label Request Message
The LDP Label Request Message is as defined in 3.5.8. of [2] with the
following modifications (required only if any of O-UNI TLVs is included
in the Label Request Message):
- The FEC TLV is ignored at the O-UNI
- The procedures to handle the Label Request Message are augmented by
the procedures for processing of the O-UNI TLVs as defined in this
section
The encoding for the O-UNI LDP Label Request Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id TLV (O-UNI mandatory) |
Aboul-Magd April 2001 5
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Id TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label Request TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Label TLV (O-UNI optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set TLV (O-UNI optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.1 Source Id TLV
The Source Id TLV is an object that specifies the initiator (the
calling party) of the lightpath creation request. The encoding of the
Source Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Source Id (0x0950) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | Channel Id | Sub-channel ID|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source User Group +-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Address:
The Node Address is the IPv4 address associated with the optical
network element
Port Id:
Port Id is a two-octet unsigned integer indicating the port number in
an optical network element
Channel Id:
Channel Id is a single octet unsigned integer indicating a channel
with respect to the specified Port Id.
Sub-Channel Id:
Aboul-Magd April 2001 6
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
Sub-Channel Id is a single octet unsigned integer indicating a sub-
channel with respect to the specified Channel Id.
Source User Group:
The Source User Group identifies the logical network or group to
which the optical client belongs. The Source User group is the 7-
octet structure as defined in [6].
6.1.2. Destination Id TLV:
The Destination Id TLV has the same structure as the Source Id TLV. The
format of the Destination Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Destination Id(0x0951) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | Channel Id | Sub-channel ID|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source User Group +-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.3. Lightpath Id TLV
The format of the Lightpath Id is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| lightpath Id (0x0952) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ActFlg|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optical network element IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ActFlag
A 4-bit field that explicitly indicates the action that should be
taken on an already existing lightpath. A set of indicator code
points is proposed as follows
0x0 = initial lightpath setup
0x1 = modify lightpath
Optical Network Element Ipv4 Address
Aboul-Magd April 2001 7
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The Ipv4 address of the optical network element
Index
A 4-octet field uniquely identifies a lightpath.
6.1.3. Generalized Label Request TLV
The Generalized Label TLV format and procedure are as defined in
section 3.1 of [4]. It supports communication of characteristics
(attributes) required for the lightpath(LSP) being requested. These
characteristics include the desired link protection, the lightpath
(LSP) encoding, and the lightpath (LSP) payload.
6.1.4. Suggested Label TLV
The Suggested Label TLV format and procedure are as defined in section
3.4. of [4].
6.1.5. Label Set TLV
The format and the procedure of the Label Set TLV is as described in
section 3.5. of [4].
6.1.6. Service TLV
The Service TLV defines the service attributes requested by the network
client. The encoding for the Service TLV 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|F| Service (0x0953) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contact ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dir | Trns | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Propagation Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contact Id:
Contact Id is a 4-octet unsigned integer that uniquely identifies the
lightpath owner. It is administratively used for call acceptance,
billing, policy decisions, etc.
Dir, Directionality
Aboul-Magd April 2001 8
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
Dir is 16-bit field that specifies the directionality of the
requested lightpath. The allowed values are:
0x0000 = Uni-directional
0x0001 = Bi-directional
0x000n = Multi-Cast with n destinations
Trans, Transparency
Transparency is interpreted with respect to the LSP encoding and
bandwidth. Trans is a 4-bit field that defines transparency
requirements of the lightpath. For SONET/SDH the allowed values are:
0x0 = PLR-C
0x1 = STE-C
0x2 = LTE-C
There are no transparency options for PDH, Digital Wrapper, and
Ethernet.
Propagation Delay
Propagation Delay is a 4-octet field. It indicates the maximum
acceptable propagation delay in ms. The recommended encoding for this
parameter is the 4-octet IEEE floating point number.
Diversity TLV
Diversity TLV lists all the other lightpaths from which the requested
lightpath MUST be diverse. It also specifies the type of diversity.
Diversity is only valid within a single routing domain. The encoding
of the Diversity TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Diversity TLV (0x0954) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DivT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DivT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DivT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboul-Magd April 2001 9
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
Lightpath TLV n:
is the Lightpath Id of the LSP from which the requested ligthpath
must be diverse.
DivT, Diversity Type
DivT specifies the manner by which the requested lightpath should be
diverse. The allowed values are:
0x0 = Link diverse
0x1 = Node diverse
0x2 = Shared Risk Link Group (SRLG) diverse
Bandwidth
It defines the lightpath bandwidth. Bandwidth is a 4-Octet number in
IEEE floating point format (the unit is bytes per second). Some
bandwidth values are enumerated in section 3.1.4. of [4]
6.1.7. Procedure
The O-UNI Label Request Message flows between an optical network client
and the edge optical network element. Upon initiating the Label Request
Message, the optical client sets the addresses in the optical network
for the two ends of the lightpath (Source Id and Destination Id TLVs).
For initial setup (ActFlg=0), the lightpath Id is set to all 0s when
sent from the client to the network. The lightpath Id is assigned by
the optical networks. It is globally unique within the optical network.
The Lightpath Id is obtained by combining the IPv4 address associated
with the optical network element and an integer index that is locally
unique. The Lightpath Id is passed to the called client in the Label
Request Message from the network to the optical client.
Upon the reception of the O-UNI Label Request Message, the edge optical
network element might consult with a policy server to verify that the
signaled attributes (including the verification of the Source and the
Destination Ids) can be supported. Failure to support one or more of
the lightpath attributes triggers the generation of the Notification
Message with the appropriate error code.
After passing the edge optical network verification process, the edge
optical network constructs the generalized MPLS message for lightpath
aetup across the optical network. The generalized Label Request Message
extracts information from the O-UNI Label Request Message with regard
to the Generalized Label Request TLV, the Suggested Label TLV, and the
Label Set TLV, whenever applicable. The methods and procedures
described in [4] are then followed for end-to-end path setup.
Lightpath modification request is achieved by the owner client sending
a Label Request Message with ActFlg=1. In this case the lightpath is
left unchanged as initially assigned by the network.
6.2. Label Mapping Message
Aboul-Magd April 2001 10
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The Label Mapping Message is as defined in 3.5.7 of [2] with the
following modifications:
- The Label Mapping Message procedures are limited to downstream
on demand ordered control mode.
The encoding of the O-UNI Label Mapping Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-UNI Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Id TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service TLV (O-UNI optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.1. Generalized Label TLV
The Generalized Label TLV format and procedures are as in section 3.2.
of [4].
6.2.2. O-UNI Label Request Message ID TLV
The O-UNI Label Request Message ID TLV has the same format and
procedures as described in [7]
6.2.3. Procedure
The O-UNI Label Mapping Message flows between an optical network client
and the edge optical network element.
The reception of the O-UNI Label Mapping Message signifies the
successful establishment of a lightpath with the desired attributes. It
also signifies the successful modification of one or more of the
lightpath attributes.
Aboul-Magd April 2001 11
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The network transports the assigned Lightpath Id to the calling client
in the Label Mapping Message. This Lightpath Id value is used by the
client and the network for the exchange of lightpath status
information.
The O-UNI Label Mapping Message also includes a Generalized Label TLV.
Its purpose is to indicate to the client label value, e.g. which
wavelength, to be used.
The O-UNI Label Mapping Message optionally includes a Service TLV that
summarizes the level of service extended from the optical network to
its client. The Service TLV must be included for the cases where
reserved lightpath attributes, e.g. its bandwidth, are different from
those requested by the customer.
6.3. The Label Release Message
The format of the O-UNI Label Release Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV (O-UNI Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.1. Procedure
The procedure for the O-UNI Label Release Message is as described in
section 3.5.11. of [2]. The O-UNI Label Release Message is sent by
either the client or the network to indicate the desire to delete an
already established lightpath. The O-UNI Label Release Message carries
a mandatory lightpath Id to indicate which lightpath should be
terminated.
6.4. The Label Withdraw Message
The format for the O-UNI Label Withdraw Message 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
Aboul-Magd April 2001 12
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV (O-UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.1. Procedure
The procedure for the Label Withdraw Message follows that defined in
section 3.5.10 of [2]. The Label Withdraw Message is sent by the
network or the client in response to a Label Release Request.
The Label withdraw Message for O-UNI carries a mandatory lightpath Id.
The reception of the Label Withdraw Message acts as an indication to
the client or the network that the lightpath defined by its Lightpath
Id has been terminated.
6.5. The Notification Message
The Notification Message is as defined in section 3.5.1. of [2] with
the following modifications:
- The O-UNI Notification Message is sent autonomously from the network
side of the O-UNI to the client to indicate the status of the lightpath
request.
- The O-UNI Notification Message includes a mandatory Lightpath 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV O-UNI (mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-UNI Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV is as defined in section 3.4.6. of [2].
Aboul-Magd April 2001 13
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
6.5.1. Procedure
The O-UNI Notification Message is used by the optical network to signal
to its clients failure condition during or after the connection
establishment phase. New Status codes relevant to lightpath operation
are:
0x00001000 = not able to connect to destination user group
0x00001001 = invalid destination address
0x00001002 = invalid port Id
0x00001003 = invalid channel Id
0x00001004 = invalid sub-channel Id
0x00001005 = bandwidth unavailable
0x00001006 = protection mode unavailable
0x00001007 = routing directive unavailable
0x00001008 = failure to create lightpath
0x00001009 = failure to modify lightpath
0x0000100A = Failure to delete lightpath
0x0000100B = Encoding unavailable
If it has been already set, the Notification Messages includes the
Lightpath Id TLV. If not set, e.g. for initial set up, the Lightpath Id
TLV is set to 0. If the Lightpath Id is not set, the Notification
Message MUST includes a O-UNI Label Request Message ID TLV as defined
in section 6.2.2.
6.6. The Status Enquiry Message
The Status Enquiry Message is a new LDP message. The encoding for the
Status Enquiry Message 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|Status Enquiry (0x0002) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.6.1 Procedure
The Status Enquiry Message is sent by the client or the network at any
time to solicit a Status Response Message from its peer. The lightpath
under consideration is identified by the Lightpath Id TLV.
6.7. The Status Response Message
Aboul-Magd April 2001 14
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The Status Response Message is a new LDP message. The encoding for the
Status Response Message 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| 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.7.1 Procedure
The Status Response Message is sent by either the client or the network
in response to Status Enquiry Message. The Status TLV carries
information that describes the current status of a connection
(ligtpath) as defined by the Lightpath Id TLV. The status of the
connection is encoded using the LDP Status TLV.
The Status Response Message could optionally include lightpath
attributes as defined by Source Id, Destination Id, and the level of
service.
6.7.1.1. Lightpath States
Connection States at the client side of the interface are:
- Null: no call exists
- Call Initiated: this state exist for an outgoing call when the client
sends the Label Request Message, but hasÆt yet received the Label
Mapping Message from the network
- Call Present: this state exist for an incoming call when the client
receives the Label Request Message from the network, but hasnÆt yet
responded to it
- Active: This state exists for an incoming call when the client sends
the Label Mapping Message to the network. The state also exist for an
outgoing call when the initiating client receives the Label Mapping
Message from the network.
Aboul-Magd April 2001 15
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
- Release Request: this state exists when the client has requested the
network to clear the end-to-end lightpath, i.e. the client sending the
Label Release Message.
- Release Indication: this state exists when the client has received an
disconnect indication because the network has already disconnected the
lightpath, i.e. when the client receives the Label Release Message.
Similar connection states exist at the network side of the interface.
The Status codes for the lightpath states are:
0x0000100C = Null
0x0000100D = Call Initiated
0x0000100E = Call Present
0x0000100F = Active
0x00001010 = Release Request
0x00001011 = Release Indication
7. Security Considerations
This security mechanisms defined in [2] shall be used.
8. Author's Addresses
Osama S. Aboul-Magd Raj Jain
Nortel Networks Nayna Networks, Inc.
P.O. Box 3511, Station ôCö 157 Topaz St.
Ottawa, Ontario, Canada Milpitas, CA 95035
Canada Phone: 408-956-8000x309
Phone: 613-763-5827 Fax: 408-956-8730
Email: Osama@nortelnetworks.com Email: Jain@nayna.com
LiangYu Jia Bala Rajagopalan
ONI Systems Corp. Tellium, Inc.
166 Baypoints Parkway 2 Crescent Place
San Jose, CA 95134 Ocean Port, NJ 07757
Phone: 408-965-2743 Phone: 732-923-4237
Fax: 408-965-2660 Fax: 732-923-9804
Email: ljia@oni.com Email:braja@tellium.com
Robert Ronnison Yangguang Xu
Laurel Networks Lucent Technologies
2607 Nicholson Rd 1600 Osgood St.
Sewickley, PA 15143 N. Anderson, MA 01845
Phone: 724-933-7330 Phone:978-960-6105
Email:robren@laurelnetworks.com Email:xuyg@lucent.com
Zhensheng Zhang
Aboul-Magd April 2001 16
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
Sorrento Networks
9990 Mesa Rim Road
San Diego, CA 92121
Phone: 858-646-7195
Email: zzhang@sorrentonet.com
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
9. References
1 Aboul-Magd, O. et. al., "Signaling Requirements at the IP-Optical
Interface (UNI)" draft-ip-optical-uni-signaling-00.txt, work in
progress, July 2000.
2 Andersson, L., et. al., "LDP Specificationsö, draft-ietf-mpls-ldp-
08.txt, work in progress, June 2000
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
4 Ashwood-Smith, P. et. Al., "Generalized MPLS - Signaling Functional
Descriptionö draft-ietf-mpls-generalized-signaling-00.txt, Work in
Progress, October 2000.
5 Ash, J., et, al., "LSP Modification Using CR-LDP", draft-ietf-mpls-
crlsp-modify-01.txt, work in progress, Feb. 2000.
6 Fox, B. and Gleeson, B., ôVPN Identifiersö, IETF RFC-2685, Sept.
1999.
7 Jamoussi, B. Editor, ôConstraint-Based LSP Setup Using LSPö, draft-
ietf-mpls-cr-ldp-04.txt, work in progress, July 2000.
Aboul-Magd April 2001 17