draft-ietf-mpls-ldp-optical-uni-00.txt   draft-ietf-mpls-ldp-optical-uni-01.txt 
MPLS Working Group Osama Aboul-Magd MPLS Working Group O. Aboul-Magd
Internet Draft Nortel Networks Internet Draft Sandra Ballare
Document: draft-ietf-mpls-ldp-optical-uni-01.txt Ewart Tempest
Nortel Networks
Raj Jain
Nayna Networks
draft-ietf-mpls-ldp-optical-uni-00.txt Raj Jain
Expiration Date: April 2001 Nayna Networks
LiangYu Jia LiangYu Jia
ONI Systems ONI Systems
Bala Rajagopalan Bala Rajagopalan
Tellium Tellium Inc.
Robert Rennison Robert Rennison
Laurel Networks Laurel Networks
Yangguang Xu Yangguang Xu
Lucent Tech Lucent Technology
Zhensheng Zhang Zhensheng Zhang
Sorrento Networks Sorrento Networks
October, 2000
July 2001
LDP Extensions for Optical User Network Interface (O-UNI) Signaling LDP Extensions for Optical User Network Interface (O-UNI) Signaling
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
and may be updated, replaced, or obsoleted by other documents at any Task Force (IETF), its areas, and its working groups. Note that
time. It is inappropriate to use Internet- Drafts as reference material other groups may also distribute working documents as Internet-
or to cite them other than as "work in progress." 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
1. Abstract 1. Abstract
General requirements for signaling across the Optical UNI (O-UNI) are In OTNs using overlay model, clients request network services
discussed in [1]. This draft describes extensions to the LDP protocol through a user network interface (UNI). This draft describes LDP
[2] to support those requirements. The LDP extensions described here necessary extensions for signaling support across the optical UNI
address two areas:
- The addition of new TLVs to support the attributes required for Aboul-Magd Expires January 2002 1
lightpath establishment at the O-UNI
Aboul-Magd April 2001 1 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
- Two new LDP messages to allow for the exchange of lightpath status (O-UNI). LDP extensions are those needed to satisfy the main
information across the UNI. functions supported at the O-UNI. Those functions are: connection
create, connection delete, connection modify, and connection status
enquiry.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119 [3]. this document are to be interpreted as described in RFC-2119 [2].
3. Use of LDP for the O-UNI 3. Introduction
This draft describes how LDP with extensions will be used as a Several models have been discussed for the support of IP traffic
signaling mechanism for the O-UNI. Several O-UNI abstract messages are over the transport layer (L1/L0) [3]. Three models are identified
defined in [1]. This draft specifies how to use the existing LDP and are differentiated based on the amount of routing/topological
messages for that purpose. Two new LDP messages are introduced to meet information exchanged between the optical transport network (OTN)
the requirements for the exchange of status information across the O- and its clients. Those models are overlay, peer, and augmented
UNI. models.
3.1. Overview In an overlay network architecture such as the ITU-T automatic
switched OTN (ASTN) [4], there is a clear boundary between the
client and the network layers. Routing and topological information
does not cross this boundary in the sense that each layer is running
its own instant of a routing protocol, e.g. OSPF or entirely
different routing protocols. Network clients request network
services, e.g. connections, across a well-defined interface. This
interface is generally called the optical user network interface (O-
UNI).
LDP is one of the candidate protocols described in [1] for O-UNI MPLS based protocols have already been proposed for the realization
signaling implementation. of the optical layer control plane in what is termed as generalized
MPLS (GMPLS) [5]. Both CR-LDP [6] and RSVP-TE [7] have been extended
for possible use as the control plane signaling protocols. It
therefore makes sense to use the same set of protocols for the
implementation of the O-UNI. This draft introduces the necessary LDP
[8] extensions to support the basic O-UNI functionality.
Applying LDP at the O-UNI allows for: At the O-UNI, four O-UNI actions are provided. Those actions are:
- The reuse of already defined LDP messages and message formats - Connection Create: Creates an end-to-end connection across the OTN
- The reuse of LDP session management and control procedures with specified connection attributes such as bandwidth, diversity,
- Additions to the already specified procedures for notification of etc. Numerous connection attributes have been articulated in [9]
errors.
- The reuse of the LDP security mechanism
Support for the O-UNI signaling requirements depends upon the use of - Connection Delete: Deletes an already existing connection.
the following LDP behaviors and mechanisms as defined in [2].
- Use of Basic and/or Extended discovery mechanisms. - Connection Modify: Modifies one or more of the connection
- Use of the Label Request Message in downstream on demand label attributes of the existing connections. Connection Modify is not
advertisement mode with ordered control. supported in this version of the draft.
- 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 Enquiry: Allows the client to enquire the status of a
status information as defined in [1]. connection or a group of connections. A connection can be in one
Additional TLVs are specified to support the lightpath attributes Aboul-Magd Expires January 2002 2
specified in [1].
Aboul-Magd April 2001 2 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
4. O-UNI Session Management and Control of a number of states such as, active, redialing, etc [9]. This
operation also allows querying connection information in order to
recover connection state.
LDP messages that relevant to the O-UNI session management and control Tightly related to the O-UNI, and any UNI in general, is the need to
are Hello Message, Initialization Message, and KeepAlive Message. uniquely identify clients and their points of attachment to the
network. An addressing scheme for the OTN has been discussed in [9].
Client identification is based on a transport network address (TNA)
that is globally unique and is assigned to the client by the network
provider. The scope of the TNA could be on a one-to-one basis with
logical links that the network provider provision between an OTN
network element (NE) and an OTN client, or it could be a single TNA
per OTN (optical transport network) client. In the latter case there
is the need to introduce a logical port identifier (LPI) to
differentiate between multiple logical links between an OTN client
and an OTN NE that share the same TNA address. Similar to the TNA,
LPI is assigned to the client by the network provider. Protocol
extensions are required to support signaling of the TNA and LPI.
4.1. Hello Message O-UNI reference models have been discussed in [9]. The client side
of the O-UNI has been denoted as UNI-C, while the term UNI-N has
been used to identify the network side of the O-UNI. One or more
signaling channels exist between the UNI-C and UNI-N. The UNI
control channel MUST support the transport of IP protocols. This
capability is necessary since IP based protocols, e.g. LDP, are
proposed for O-UNI signaling.
This draft does not change the format or the procedures of the LDP 4.0 LDP for the O-UNI
Hello Message as described in section 3.5.2. of [2].
4.2. KeepAlive Message In extending LDP for implementation at the O-UNI, there have been
two main guiding principles. Firstly every effort was made to limit
the introduction of new LDP messages. New messages are only
introduced whenever the desired functionality could not be supported
by existing messages, and have been limited to only those required
to support the status enquiry function of the O-UNI.
This draft does not change the format or the procedures of the LDP Secondly care has been taken not to violate any of the LDP semantics
KeepAlive Message as defined in section 3.5.4 of [2]. as defined in [8]. Therefore LDP O-UNI extensions could easily be
implemented as a simple add-on to the already existing LDP
implementations.
4.3. Initialization Message The mode of operation of the LDP at the O-UNI is downstream on
demand label advertisement with ordered control.
The Initilaization Message is as defined in section 3.5.3 of [2] with 4.1 LDP Session Initialization
the following modifications:
- The Label Advertisement Discipline (the ˘A÷ bit) is always set at 1 For the O-UNI the LDP session is established between UNI-C and UNI-
to indicate Downstream on Demand label distribution mode. Downstream on N. Furthermore the client (UNI-C) MUST play the active role during
Demand is the only label distribution mode supported at the O-UNI. The the LDP session initialization phase. Moreover, if all logical links
assignment A=0 should result in generating a Notification Message with are in the same O-VPN,:
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 - There will be a single LDP session between an OTN client and an
OTN NE, regardless of the number of logical links between them.
A set of abstract O-UNI messages is defined in [1]. Those abstract Aboul-Magd Expires January 2002 3
messages support the basic functions of the optical UNI. Those
functions are,
- Lightpath Create: Creates a lightpath with certain attributes between Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
two ends in the optical networks
- Lightpath Delete: Deletes an already existing lightpath - In the case of proxy signaling, there will be a single LDP session
between a proxy agent and an OTN NE regardless of the number of
OTN clients and logical links the proxy agent signals on behalf
of.
- Lightpath Modify: Modifies one or more of the attributes of already The LDP Hello and Extended Hello SHALL be used for neighbor
existing lightpath discovery as specified in [8].
- Lightpath Status Enquiry: Enquires about the status of an already An LDP session starts by UNI-C sending an LDP Initialization message
existing lightpath to its neighbor UNI-N over the TCP session. In addition to the
parameters described in [8], the Initialization message from the
UNI-C to the UNI-N contains all the O-UNI version numbers that are
supported by the UNI-C.
Each of the above functions is accomplished by a set of O-UNI messages The UNI-N follows the procedure specified in section 2.5.3 of [8]
using LDP protocol.The procedures for handling LDP messages across the for the passive LSR. It replies with an Initialization message to
optical UNI are augmented to add the additional O-UNI functionality. propose the parameters it wishes to use. Those parameters MUST
Common across the O-UNI are: include the highest version number from the list advertised by the
UNI-C that the UNI-N supports. If the UNI-C and UNI-N have no UNI
version in common, the LDP session establishment will fail.
Aboul-Magd April 2001 3 The Initialization message also includes a Contract ID TLV. Contract
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 ID is determined by the network provider and identifies the contract
agreement between the OTN client and the OTN operator. Its format is
determined by the OTN operator.
- The LDP FEC TLV should be ignored at the O-UNI since it has no Maintaining the LDP session at the O-UNI MUST follow the procedure
significance, and explained in section 2.5.6 of [8].
- The use of LDP messages for O-UNI does not change the semantics of
the LDP Message ID.
5.1. Lightpath Create Action 4.2 Connection Create using LDP
Lightpath Create Action requires two messages, the lightpath Create In LDP, the connection create request is implemented using the Label
Request and the Lightpath Create Response. The mapping of the LDP Request message as defined in [8]. The Label Request message is from
messages to fulfill the lightpath create action is: the source UNI-C to the source UNI-N. At the other end of the
network the Label Request message is sent from the destination UNI-N
to destination UNI-C.
- Lightpath Create Request: The create request function is achieved by The requested connection might need to support a number of
the LDP Label Request Message. The Generalized Label Request TLV attributes. Extensions are needed to the Label Request message to
defined in [4] is used to convey some lightpath attributes to the support the client signaling of those attributes.
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 OTN connections are usually bi-directional. As in GMPLS, a bi-
directional connection is signaled at the O-UNI by the inclusion of
the Upstream Label in the Label Request message. Reception of the
Label Request message by the destination UNI-C signifies the
reservation success, i.e. all the requested connection attributes
can be satisfied, of the bi-directional connection. However it
doesnĂt imply that the connection is available for data transport.
Connection is only available when configuration of intermediate
cross connects is complete. The Configuration of any intermediate
cross connect likely to require some time to complete and, depending
on the technology used, this delay may be significant, e.g. in the
order of 10's or 100's of ms.
Lightpath Delete Action requires two messages, Aboul-Magd Expires January 2002 4
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 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
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 The destination UNI-C sends a Label Mapping message in response to
the Label Request message, only once it has setup its own switch
fabric. If it so desires, the destination UNI-C MAY indicate to the
source UNI_C that a reservation confirmation indication is needed.
The reservation confirmation indication is implemented using the LDP
Notification message with the status code ˘reservation_confirm÷. In
general, Uni-directional connections do not require a reservation
confirmation indication, and depending on the nature of the
application on the destination OTN client that terminates the OTN
connection, maybe not even in the case of bi-directional
connections.
After a lightpath is setup, some of its attributes, e.g. bandwidth, may Contention for labels may occur between two bidirectional connection
need to be changed by the network operator due to new requiremenst for setup requests traveling in opposite directions. This contention
the traffic carried on that lightpath. Lightpath Modify Action does not occurs when both sides allocate the same resources (labels) at
require the definition of new LDP messages. The modify action follows effectively the same time. To resolve contention, the node with the
the procedure described in [5]. higher node ID will win the contention and it MUST issue a
NOTIFICATION message with a "Routing problem/Label allocation
failure" indication. Upon receipt of such an error, the node SHOULD
try to allocate a different Upstream label (and a different Suggested
Label if used) to the bidirectional path. However, if no other
resources are available, the node must proceed with standard error
handling.
Lightpath modification can only be allowed when the lightpath is Similarly the source UNI-N sends a Label Mapping message to the
already established. The procedure described in [5] allows for source UNI-C. At this instant the transport connection is available
modification of lightpath attributes without service interruption. Only to the source UNI-C for use provided that its own switch fabric have
modifications requested by the owner of a particular lightpath are been setup. Figure 1 shows a timing diagram for a successful
allowed. establishment of a bi-directional connection.
Aboul-Magd April 2001 4 UNI-C UNI-N UNI-N UNI-C
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 | | | |
| | | |
Label |------>| | |
Request | |-------------->| | Label
| | |------>| Request
| | | |
| | | |
| | |<------| Label
Label | |<--------------| | Mapping
Mapping |<------| | |
| | | |
Reservation |------>| | | Reservation
Confirm | | |------>| Confirm
| | | |
The procedure described in [5] for lightpath modification relies on the Figure 1: Successful Setup of Bi-Directional Connection
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 The connection create request might fail for a number of reasons,
e.g. no bandwidth available, no physical connectivity, SLA
violation, connection rejected by far end OTN client. In this case
failure of the create request is indicated to the source UNI-C using
the LDP Notification message with the status code reflecting the
Lightpath Status Actionrequires two messages, Lightpath Status Enquiry Aboul-Magd Expires January 2002 5
and Lightpath Status Response
The Lightpath Status Enquiry and Lightpath Status Response functions Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
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 reason for the failure. Figure 2 shows a create request rejection by
the netwok.
The Notification function is similar in scope to that of the CR-LDP UNI-C UNI-N UNI-N UNI-C
Notification Message. Hence the LDP Notification message is used across | | | |
the O-UNI for this purpose. | | | |
Label |------>| | |
Request | | | |
| | | |
| | | |
Notification |<------| | |
| | | |
6. LDP Message Extensions Figure 2: Connection Setup Rejection by the Network
This section gives detailed description of LDP message extensions for Should a client desire to abort the connection create process after
the support of O-UNI. sending the Label Request message, an LDP Abort message MUST be sent
as defined in section 3.5.9. of [8]. Specifically the Message ID
used in the Label Request Message is used in the Abort Message as
the temporary local connection identifier.
6.1. Label Request Message 4.3 Connection Deletion Using LDP
The LDP Label Request Message is as defined in 3.5.8. of [2] with the LDP employs two mechanisms for an LSR (label switched router) to
following modifications (required only if any of O-UNI TLVs is included inform its peer to stop using a particular label. The first method
in the Label Request Message): is based on the use of Label Withdraw message and it is used to
signal to a peer that the peer may not continue to use a specific
label mapping that the LSR has previously advertised. The second
method is based on the use of Label Release message and it is sent
to signal to a peer that the LSR no longer needs a specific label
mapping previously requested and/or advertised by the peer.
- The FEC TLV is ignored at the O-UNI The O-UNI LDP extensions make use of the Label Release and Label
Withdraw messages for connection deletion. The choice of which
message to use depends on the entity that initiates the deletion.
The Label Withdraw message is used for the case where the connection
deletion is in the upstream direction. As per the LDP procedure in
section 3.5.10 of [8], Label Release message is used in this case to
acknowledge the delete request.
- The procedures to handle the Label Request Message are augmented by The Label Release message is used for the cases where connection
the procedures for processing of the O-UNI TLVs as defined in this deletion is in the downstream direction. In this case the delete
section request is confirmed by the use of LDP Notification message with the
status code "delete_success".
The encoding for the O-UNI LDP Label Request Message is as follows: Figures 3 and 4 show graceful connection deletion requested by the
source UNI-C and the destination UNI-C respectively.
UNI-C UNI-N UNI-N UNI-C
| | | |
| | | |
Notification |------>| | |
| |-------------->| |
Aboul-Magd Expires January 2002 6
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
| | |------>| Notification
| | | |
| | |<------| Label Withdraw
| |<--------------| |
Label Withdraw |<------| | |
Label release |------>| | |
| |-------------->| |
| | |------>| Label Release
| | | |
Figure 3: Graceful Connection Deletion by the Source UNI-C
UNI-C UNI-N UNI-N UNI-C
| | | |
| | |<------| Notification
| |<--------------| |
Notification |<------| | |
Label Release |------>| | |
| |-------------->| |
| | |------>| Label Release
| | |<------| Notification
| |<--------------| |
Notification |<------| | |
| | | |
Figure 4: Graceful Connection Deletion by the Destination UNI-C
Figure 3 shows that the delete request is preceded by an LDP
Notification message with status code ˘delete_indication÷. In all
optical networks, loss of light will propagate faster than the
delete request. Thus downstream NE will detect loss of light and
potentially alarm on it. This alarm could be used to incorrectly
trigger restoration and/or protection. To address this issue, a
Notification message SHOULD be sent along the connection's route to
inform all nodes of the intended deletion. Upon the receipt of this
message, each node SHOULD disable its alarm reporting and protection
mechanisms on the indicated connection.
Figure 5 shows a connection deletion scenario initiated by the
network, or a force deletion requested from an OAM entity. In this
case both Label Withdraw and Label Release messages are used to
initiate the deletion request.
UNI-C UNI-N UNI-N UNI-C
| | | |
| | | |
Label |<------| |------>| Label
Withdraw | | | | Release
| | | |
Label |------>| |<------|
Aboul-Magd Expires January 2002 7
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
Release | | | |Notification
| | | |
Figure 5: Connection Deletion Initiated by the Network
4.4 Failure Detection and Recovery Using LDP
In optical transport networks, failures in the out-of-fiber
signaling communication or optical UNI control plane should not have
service impact on the existing optical connections. Under such
circumstances, a mechanism MUST exist to detect a signaling
communication failure and a recovery procedure SHALL guarantee
connection integrity at both UNI-C and UNI-N.
The LDP Keep Alive mechanism MUST be used to detect signaling
communication failures between a UNI-C and a UNI-N, unless an
alternative mechanism is in place to detect such failures more
efficiently. During the signaling communication failure all active
connections are maintained (the bearer connection is active) and all
transient connections (in-progress) are cleared.
Upon signaling communication re-establishment (i.e. re-establishment
of LDP Keep Alive) a resynchronization period is required in order
to synchronize connection state information across the UNI. This
synchronization period shall be performed prior to processing new
connection requests.
The resynchronization period starts by the UNI-C either querying the
network (UNI-N) for the (summary or detailed) states of all
connections associated with a particular logical link, or otherwise
(implicitly or explicitly) deleting them. In the former case, the
UNI-N will respond with appropriate status information. The OTN is
the master of all oTN connection information. An OTN connection,
once created, remains within the OTN until implicitly or explicitly
deleted by either of the terminating OTN clients through UNI
signaling, or via OTN operator intervention. Specifically the burden
is on the OTN client to resynchronize with the OTN. Under no
circumstances will the OTN resynchronize with its OTN connection
view with that of an OTN client.
There are three cases to consider during recovery:
a) Both UNI-C and UNI-N have retained connection information during
the signaling communication failure. In this case, the recovery
consists of synchronizing connection state information. This
synchronization process requires UNI-C to send Status Enquiry
messages requesting summary connection information.
b) The client device lost all connection information in its UNI-C
control plane during the signaling communication failure. In this
case, the recovery procedure requires the UNI-C to query each
connection to its peer UNI-N in order to rebuild the connection
state information. This can be performed using the Status Enquiry
Aboul-Magd Expires January 2002 8
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
message(s) requesting detailed connection information based on LDP
session, logical link or TNA address.
c) The client device lost all connection information in its UNI-C
control plane and requires all OTN connections to be deleted on:
- A per LDP session basis.
- A specific logical link
- All logical links that share a specified TNA address
In this case, the synchronization is a simple restart process that
can be achieved by sending a Label Release message with the
corresponding TNA and optional logical port parameters. Figure 6
shows the scenario for graceful and forced deletion of all
connection in this case (for the purpose of simplicity, the
diagram assumes that the OTN connections to be deleted all
terminate on the same destination OTN client. In reality, this
will almost certainly not be the case). Graceful deletion is
indicated by source UNI-N sending a Notification message
indicating the intended delete. This Notification message is
OPTIONALLY sent in response to the source UNI-C Label Release
message. For multiple destinations a separate Notification message
SHLL be sent per destination.
UNI-C UNI-N UNI-N UNI-C
| | | |
Label Release |------>| | |
| |-------------->| |
| | |------>| Notification
| | |<------| Label Withdraw
| |<--------------| |
| | | |
| |-------------->| |
| | | |
| | |------>| Label Release
Notification |<------| | |
| | | |
Figure 6: Deletion of All Connections
Resynchronization is deemed to be complete between a given OTN
client and OTN NE when each connection for which OTN NE knows about
is either queried or deleted by the OTN client. Until such time, no
new connections can be established for which the OTN client would be
a terminating point.
5.0 LDP Extensions for O-UNI
This section describes LDP extensions specific for the support of
signaling across the optical UNI.
5.1 TLV Encoding for Commonly Used Parameters
Aboul-Magd Expires January 2002 9
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
The TLV encoding described in section 3.4 of [8] and in [10] MUST be
applicable at the O-UNI. This section describes the O-UNI specific
TLV encoding.
5.1.1 Src ID TLV
A client used the Src ID TLV to indicate its identification
parameters. The Src ID TLV MUST contain the source TNA, and
OPTIONALLY contain a Logical Link ID. The encoding for the Src ID
is:
0 1 2 3 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 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 | |U|F| Src TNA Value | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | |
~ Src TNA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | Logical Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id TLV (O-UNI mandatory) |
Aboul-Magd April 2001 5 Src TNA:
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 Src TNA can be in one of three formats [9]. It can be in either
IPv4, IPv6, or NSAP format. Only TNA addresses of the same type
can be compared for equivalence. The Src TNA values are:
Value Type
------- -------
0x960 IPv4
0x961 IPv6
0x962 NSAP
The NSAP format is structured according to ISO/IEC 8348, 1993
(identical to ITU X.213, 1992)
Only TNA addresses of the same type SHOULD be compared for
equality.
Logical Port ID:
A 32-bit unsigned number indicating identifying a logical port at
the source OTN NE. Logical Port ID is OPTIONAL and, as such, may
not be present.
5.1.2 Dest ID TLV
Dest ID TLV is used to identify the destination end of the
connection. The Dest ID TLV encoding 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Id TLV (O-UNI mandatory) | |U|F| Dest TNA Value | Length |
Aboul-Magd Expires January 2002 10
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV (O-UNI mandatory) | | |
~ Dest TNA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label Request TLV (O-UNI mandatory) | | Logical Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Label TLV (O-UNI optional) |
Dest TNA:
Similar to the Src TLV, the following values MUST be supported
Value Type
------- -------
0x963 IPv4
0x964 IPv6
0x965 NSAP
The NSAP format is structured according to ISO/IEC 8348, 1993
(identical to ITU X.213, 1992)
Only TNA addresses of the same type SHOULD be compared for
equality.
Logical Port ID:
A 32-bit unsigned number indicating identifying a logical port at
the destination client device. Logical Port ID is OPTIONAL and, as
such, may not be present.
5.1.3 Egress Label TLV
Egress Label TLV is an OPTIONAL O-UNI defined TLV. Egress Label TLV,
when present, indicates the egress label to be used at the
destination end of the O-UNI. The encoding for the Egress Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set TLV (O-UNI optional) | |U|F| Egress Lbl (0x0957) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service TLV (O-UNI mandatory) | | Reserved |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | |
~ Label ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.1.1 Source Id TLV L-bit:
If L=0, then the Label value MUST be copied into Label Set TLV in
the corresponding outgoing Label Request message from the
destination UNI-N to destination UNI-C. If L=1, then the Label
value MUST be copied into an Upstream Label TLV in corresponding
outgoing Label Request message from the destination UNI-N to the
destination UNI-C. As such, the Label Request message originated
The Source Id TLV is an object that specifies the initiator (the Aboul-Magd Expires January 2002 11
calling party) of the lightpath creation request. The encoding of the
Source Id TLV is: Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
by the source UNI-C may contain up to two Egress Label TLVs, one
with the L-bit set, and the other with the L-bit not set.
5.1.4. Connection ID TLV
The Connection ID TLV is used to uniquely identify a connection
established by the network. The format of the Connection ID TLV is
as follows:
0 1 2 3 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 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 | |U|F| Connection ID (0x0952) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | Channel Id | Sub-channel ID| | Reserved |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Source User Group +-+-+-+-+-+-+-+-+ ~ Connection ID ~
| | Reserved | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node Address: C-bit:
The Node Address is the IPv4 address associated with the optical The value of the C bit is set by the destination UNI-C whenever a
network element reservation confirmation indication is needed.
Port Id: Connection ID:
Port Id is a two-octet unsigned integer indicating the port number in Connection ID has a variable length in multiple of 32, and is at
an optical network element least 64 bits wide.
Channel Id: 5.1.5 Diversity TLV
Channel Id is a single octet unsigned integer indicating a channel
with respect to the specified Port Id.
Sub-Channel Id: Diversity TLV lists all the other connections from which the
requested connection MUST be diverse. It also specifies the type of
diversity. The encoding of the Diversity TLV is as follows:
Aboul-Magd April 2001 6 0 1 2 3
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 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| Diversity TLV (0x0954) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | DivT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | DivT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Channel Id is a single octet unsigned integer indicating a sub- Connection ID TLV i:
channel with respect to the specified Channel Id. This is the Connection ID of an existing connection from which
the requested connection must be diverse.
Source User Group: Aboul-Magd Expires January 2002 12
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: Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
The Destination Id TLV has the same structure as the Source Id TLV. The DivT (Diversity Type):
format of the Destination Id TLV is: DivT specifies the manner by which the requested connection
should be diverse. The allowed values are:
0x0 = Link diverse
0x1 = Node diverse
0x2 = Shared Risk Link Group (SRLG) diverse
0x3 = Link non-diverse
0x4 = Node non-diverse
0x5 = SRLG non-diverse
5.1.6 Contract ID TLV
0 1 2 3 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 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 | |U|F|Contract ID TLV (0x0956) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | Channel Id | Sub-channel ID|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Source User Group +-+-+-+-+-+-+-+-+ ~ Contract ID ~
| | Reserved | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.3. Lightpath Id TLV Contract ID:
This is a variable-length string of characters whose format will
be determined by the OTN provider. Contract ID identifies the
contracted service level agreement (SLA) that the OTN client has
with the OTN operator, and in whose context the connection setup
request is made. Contract IDs therefore only have local
significance between an OTN client and an OTN NE.
The format of the Lightpath Id is as follows: 5.1.8 O-UNI Service TLV
The O-UNI Service TLV describes connection attributes in terms of
restoration and routing diversity. The encoding of the O-UNI Service
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| lightpath Id (0x0952) | Length | |U|F| O-UNI Service (0x0953) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ActFlg|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optical network element IPv4 address | | Reserved | Service Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | | Diversity TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ActFlag Service Level:
A 4-bit field that explicitly indicates the action that should be A Service Level corresponds to carrier-defined characteristics
taken on an already existing lightpath. A set of indicator code such as time to restore, BER, bumping priority, etc.
points is proposed as follows
0x0 = initial lightpath setup
0x1 = modify lightpath
Optical Network Element Ipv4 Address 5.1.9 O-UNI Version Number TLV
Aboul-Magd April 2001 7 Aboul-Magd Expires January 2002 13
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The Ipv4 address of the optical network element Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
Index The O-UNI Version Number TLV is of the form:
A 4-octet field uniquely identifies a lightpath.
6.1.3. Generalized Label Request 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|Version Num TLV (0x0955) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Major Vesrion Number | Minor Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Generalized Label TLV format and procedure are as defined in Minor version number is set relative to the major version number.
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 5.2 LDP Message Extensions for O-UNI
The Suggested Label TLV format and procedure are as defined in section This section describes the necessary extensions for LDP messages for
3.4. of [4]. the support of signaling across the O-UNI. This section also
includes the definition of the two new messages needed for status
enquiry. Those messages are Status Enquiry message and Status
Response Message.
6.1.5. Label Set TLV 5.2.1 Hello Message
The format and the procedure of the Label Set TLV is as described in The format and the procedure for the Hello message is as defined in
section 3.5. of [4]. section 3.5.2 in [8].
6.1.6. Service TLV 5.2.2 Initialization Message
The Service TLV defines the service attributes requested by the network The encoding for the Initialization message is:
client. The encoding for the Service TLV is as follows:
0 1 2 3 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 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 | |0| Initialization (0x0200) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contact ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dir | Trns | Reserved | | Common Session Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Propagation Delay | | O-UNI Version Number TLV (O-UNI Mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity TLV | ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth | | O-UNI Version Number TLV (O-UNI Mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contract ID TLV (O-UNI Mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contact Id: The initialization message procedure is as described in section 2.5.
Contact Id is a 4-octet unsigned integer that uniquely identifies the in [8] and section 4.1 of this draft.
lightpath owner. It is administratively used for call acceptance,
billing, policy decisions, etc.
Dir, Directionality
Aboul-Magd April 2001 8 Message ID is as defined in section 3.5. in [8]. Common Session
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 Parameter TLV is as defined in section 3.5.3 in [8].
Dir is 16-bit field that specifies the directionality of the Aboul-Magd Expires January 2002 14
requested lightpath. The allowed values are:
0x0000 = Uni-directional Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
0x0001 = Bi-directional
0x000n = Multi-Cast with n destinations
Trans, Transparency The currently defined values for the O-UNI version Number are:
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 For OIF Demo UNI:
0x1 = STE-C Major Version Number = 0x0000, Minor Version Number = 0x0001
0x2 = LTE-C
There are no transparency options for PDH, Digital Wrapper, and For OIF UNI 1.0:
Ethernet. Major Version Number = 0x0001, Minor Version Number = 0x0000
Propagation Delay 5.2.3 Label Request Message
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 The encoding of the Label Request Message for O-UNI is:
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
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 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 | |0| Label Request (0x0401) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV 1 | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DivT | Reserved | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV 2 | | Src ID TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DivT | Reserved | | Dest ID TLV TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . . . . ~ | Egress Label TLV (UNI Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV n | | Connection ID TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DivT | Reserved | | Generalized Label Request TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-UNI Service TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SONET/SDH Traffic Parameters TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Label TLV (UNI optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Label TLV (UNI optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set TLV (UNI optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboul-Magd April 2001 9 The Label Request Message is sent from:
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 - the source UNI-C to source UNI-N to indicate an outgoing
and the edge optical network element. Upon initiating the Label Request connection request;
Message, the optical client sets the addresses in the optical network - the destination UNI-N to the destination UNI-C to indicate an
for the two ends of the lightpath (Source Id and Destination Id TLVs). incoming connection request.
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 Aboul-Magd Expires January 2002 15
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 Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
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 How the Label Request message is propagated through OTN from the
a Label Request Message with ActFlg=1. In this case the lightpath is source UNI-N to the destination UNI-N is outside the scope of this
left unchanged as initially assigned by the network. specification.
6.2. Label Mapping Message In the Label Request Message, the initiating UNI-C identifies the
two connection termination points (Src and Dest ID TLVs). The UNI-N
is expected to assign a Connection ID that is unique within the
transport network. The Connection ID is passed to the terminating
UNI-C in the Label Request Message by the destination UNI-N.
Aboul-Magd April 2001 10 Upon the reception of the Label Request Message, the source UNI-N
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 should verify that the signaled attributes (including the validity
of the Source and the Destination IDs) can be supported. Failure to
support one or more of the connection attributes triggers the
generation of the Notification Message with the appropriate error
code.
The Label Mapping Message is as defined in 3.5.7 of [2] with the The Label Request message Message ID should be used as a local
following modifications: connection identifier, until such a time when the network-assigned
Connection ID is sent back to the source client. As stated in [8],
since LSRs use Label Request message IDs as transaction identifiers,
an LSR SHOULD NOT reuse the Message ID of a Label Request message
until the corresponding transaction completers. Thus the local
connection identifier has a very limited lifespan.
- The Label Mapping Message procedures are limited to downstream 5.2.4 Label Mapping Message
on demand ordered control mode.
The encoding of the O-UNI Label Mapping Message is as follows: The format of the Label Mapping message for the O-UNI is:
0 1 2 3 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 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 | |0| Label Mapping (0x0400) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV (O-UNI mandatory) | | Generalized Label TLV (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) | | UNI Label Request Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service TLV (O-UNI optional) | | Connection ID TLV (UNI mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.1. Generalized Label TLV The Label Mapping message procedure for the O-UNI is limited to
The Generalized Label TLV format and procedures are as in section 3.2. downstream on demand ordered control mode. The UNI Label Mapping
of [4]. Message flows between:
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 - The destination UNI-C to destination UNI-N in response to a Label
and the edge optical network element. Request message;
The reception of the O-UNI Label Mapping Message signifies the Aboul-Magd Expires January 2002 16
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-01 July, 2001
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
The network transports the assigned Lightpath Id to the calling client - The source UNI-N to the source UNI-C to indicate the successful
in the Label Mapping Message. This Lightpath Id value is used by the establishment of a connection requested previously.
client and the network for the exchange of lightpath status
information.
The O-UNI Label Mapping Message also includes a Generalized Label TLV. The network transports the assigned Connection ID to the calling
Its purpose is to indicate to the client label value, e.g. which client (source UNI-C) in the Label Mapping Message.
wavelength, to be used.
The O-UNI Label Mapping Message optionally includes a Service TLV that A terminating UNI-C that desires to receive a reservation
summarizes the level of service extended from the optical network to confirmation from the initiating UNI-C MUST set the C-bit in the
its client. The Service TLV must be included for the cases where Connection ID TLV.
reserved lightpath attributes, e.g. its bandwidth, are different from
those requested by the customer.
6.3. The Label Release Message 5.2.5 Label Release Message
The format of the O-UNI Label Release Message is as follows: The encoding for the Label Release message at the O-UNI is:
0 1 2 3 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 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 | |0| Label Release (0x0403) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized Label TLV (O-UNI Optional) | | Connection ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV (O-UNI mandatory) | | Src ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.1. Procedure The LDP Label Release Message is used for connection deletion in the
downstream direction, e.g. when the connection termination is
initiated by the destination UNI-C (graceful OTN connection
deletion) / source UNI-C (non-graceful OTN connection deletion). The
O-UNI Label Release Message is sent by:
The procedure for the O-UNI Label Release Message is as described in - The source UNI-C to source UNI-N to request the deletion a
section 3.5.11. of [2]. The O-UNI Label Release Message is sent by connection;
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 destination UNI-N to a destination UNI-C to indicate the
deletion of a connection by the network.
The format for the O-UNI Label Withdraw Message is as follows: For the optical UNI, the receiver of the Label Release Message must
respond with a Notification Message with the appropriate status code
indicating the success of the delete request.
0 1 2 3 Either the Connection ID TLV or the Src ID TLV MUST be included in
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 the Label Release Message. When the Connection ID TLV is included,
it is an indication that the connection identified by this ID is the
one to be deleted. The Src ID TLV will only be present if a forced
(i.e. non graceful) OTN connection deletion is to be performed.
Aboul-Magd April 2001 12 When the Src ID TLV is included, it is an indication to the network
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 that the source UNI-C requires deletion of all the connections
Aboul-Magd Expires January 2002 17
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
associated with the specified logical link. This feature is
primarily used for forced deletion of connections in failure
recovery.
5.2.6 Label Withdraw Message
The encoding for the Label Withdraw message at the O-UNI 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| Label Withdraw (0x0402) | Length | |0| Label Withdraw (0x0402) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV (O-UNI mandatory) | | Connection ID TLV (UNI Mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4.1. Procedure The LDP Label Withdraw message is used for connection deletion in
the upstream direction, e.g. when the connection termination is
initiated by the destination UNI-C (non-graceful OTN connection
deletion) / source UNI-C (graceful OTN connection deletion). The UNI
Label Withdraw Message is sent by:
The procedure for the Label Withdraw Message follows that defined in - The destination UNI-C to destination UNI-N to request the deletion
section 3.5.10 of [2]. The Label Withdraw Message is sent by the of a connection
network or the client in response to a Label Release Request. - The source UNI-N to the source UNI-C to indicate the deletion of
the connection by the network.
The Label withdraw Message for O-UNI carries a mandatory lightpath Id. The procedure for the Label Withdraw Message is defined in section
The reception of the Label Withdraw Message acts as an indication to 3.5.10 of [8]. The recipient of the Label Withdraw Message MUST
the client or the network that the lightpath defined by its Lightpath respond with a Label Release message as in [8]. The Label Withdraw
Id has been terminated. message for UNI carries a mandatory Connection ID.
6.5. The Notification Message 5.2.7 Label Abort Message
The Notification Message is as defined in section 3.5.1. of [2] with The format and the procedure of the Label Abort message are as given
the following modifications: in section 3.5.9 of [8].
- The O-UNI Notification Message is sent autonomously from the network 5.2.8 Notification Message
side of the O-UNI to the client to indicate the status of the lightpath
request. The format of the Notification for the O-UNI is:
- The O-UNI Notification Message includes a mandatory Lightpath Id TLV
0 1 2 3 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 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 | |0| Notification (0x0001) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath Id TLV O-UNI (mandatory) |
Aboul-Magd Expires January 2002 18
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
| Connection ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-UNI Label Request Message ID TLV | | Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV | | Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV is as defined in section 3.4.6. of [2]. The UNI Notification Message must be forwarded towards the entity
originating the Label Request, Label Release, Status Enquiry, or
Abort.
Aboul-Magd April 2001 13 The Notification message plays a number of roles within the O-UNI:
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000
6.5.1. Procedure - A failed connection setup event is indicated to the source UNI-C
using a Notification message. In this case, the Notification
message is generated in response to a Label Request message before
the source client has been made aware of its associated Connection
ID. Therefore, in this case, the Notification message MUST include
the Label Request Message ID TLV that specifies the Message ID of
the Label Request message of the failed setup (and which
constitutes the source OTN client local connection identifier).
The Status TLV MUST include the status code for the cause of the
failed setup, e.g. "no_bandwidth_available".
The O-UNI Notification Message is used by the optical network to signal - A Notification message is needed to initiate graceful deletion of
to its clients failure condition during or after the connection a single OTN connection. In this case the Notification message
establishment phase. New Status codes relevant to lightpath operation MUST include the Connection ID of the connection to be deleted.
are: The "delete_indication" status code must be included.
0x00001000 = not able to connect to destination user group - A Notification message is sent in response to a connection
0x00001001 = invalid destination address deletion in the downstream direction, i.e. initiated by a Label
0x00001002 = invalid port Id Release message. In this case the Status TLV MUST include the
0x00001003 = invalid channel Id status code for "delete_success". The Notification message can be
0x00001004 = invalid sub-channel Id sent in response to a single connection deletion or the deletion
0x00001005 = bandwidth unavailable of all the connection associated with a source identification
0x00001006 = protection mode unavailable point (LDP session, logical link, or TNA address). For single
0x00001007 = routing directive unavailable connection deletion the Notification message MUST include the
0x00001008 = failure to create lightpath Connection ID of the deleted connection. When used to acknowledge
0x00001009 = failure to modify lightpath the deletion of a group of connections, the Notification message
0x0000100A = Failure to delete lightpath MUST not contain IDs of any of the connections that were deleted.
0x0000100B = Encoding unavailable
If it has been already set, the Notification Messages includes the - A Notification message is sent for those cases where the
Lightpath Id TLV. If not set, e.g. for initial set up, the Lightpath Id destination UNI-C requests a reservation confirmation indication
TLV is set to 0. If the Lightpath Id is not set, the Notification from the source UNI-C. In this case the status TLV MUST include
Message MUST includes a O-UNI Label Request Message ID TLV as defined the "reserv_confirm" status code.
in section 6.2.2.
6.6. The Status Enquiry Message - A Notification message is sent for those cases where the source
UNI-C attempts to abort a connection request after sending the
Label Request Message. The Notification message is sent in
response to an Abort message. In this case the Notification
message MUST include the Label Request Message ID TLV.
The Status Enquiry Message is a new LDP message. The encoding for the Aboul-Magd Expires January 2002 19
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
The use of the Notification message for the O-UNI includes those
procedures that are specified in [8].
5.2.9 Status Enquiry Message
The Status Enquiry is a new LDP message that is defined specifically
for LDP applications for O-UNI signaling. The encoding for the
Status Enquiry Message is: Status Enquiry Message is:
0 1 2 3 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 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 | |U|F| Status Enquiry (0x0420) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV | | Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src ID TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src ID TLV m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.6.1 Procedure The Status Enquiry message allows a client to enquire about the
status of a connection or group of connections for which the client
is an end point.
The Status Enquiry Message is sent by the client or the network at any When a Src ID TLV is present in the Status Enquiry message, the
time to solicit a Status Response Message from its peer. The lightpath client is in effect requesting the status of all connections
under consideration is identified by the Lightpath Id TLV. associated with the specified logical link.
6.7. The Status Response Message When a Connection ID TLV is present in the Status Enquiry message,
the client is requesting the status of this particular connection.
Aboul-Magd April 2001 14 Status Enquiry can be generated by the client at any time. The
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 Status Enquiry message is used to enquire about status of already
existing connections.
The Status Response Message is a new LDP message. The encoding for the S-bit:
Status Response Message is:
Aboul-Magd Expires January 2002 20
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
Whenever the S bit is set, S=1, it indicates that the Status
Enquiry message is for summary information. In that case the
Status Response message contains summary information (Connection
ID and connection Status) of the specified connections. Otherwise,
S=0, detailed information is requested.
5.2.10 Status Response Message
The Status Response message is a new LDP message that is defined
specifically for LDP applications for O-UNI. The encoding for the
Status Response message is:
0 1 2 3 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 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 | |U|F| Status Response (0x0421) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath ID TLV | | Connection ID TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id TLV | | Src ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID TLV | | Dest ID TLV TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service TLV | | Egress Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-UNI Service TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SONET/SDH Traffic Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O-UNI Service TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SONET/SDH Traffic Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
Aboul-Magd Expires January 2002 21
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV | | Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.7.1 Procedure The Status Response message is generated in response to a Status
Enquiry message. The Status Response message contains information
regarding the status of those connections (implicitly or explicitly)
specified in the Status Enquiry message to which it is a response.
The amount information included in the Status Response message
depends on the whether the Status Enquiry is for summary or detailed
information.
The Status Response Message is sent by either the client or the network 6.0 Status Code Summary
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 The following are the status codes defined for this version of LDP
attributes as defined by Source Id, Destination Id, and the level of O-UNI protocol.
service.
6.7.1.1. Lightpath States 0x000000xx = destination_not_reachable
0x000000xx = invalid_destination_TNA
0x000000xx = bandwidth_unavailable
0x000000xx = protection_mode_unavailable
0x000000xx = routing_directive_unavailable
0x000000xx = Failure_to_delete_connection
0x000000xx = Encoding_unavailable
0x000000xx = bad_egress_label
0x000000xx = delete_indication
0x000000xx = delete_success
0x000000xx = reserv_confirm
0x000000xx = abort_complete
Connection States at the client side of the interface are: 0x000000xx = Connection active
0x000000xx = Connection doesn't exist
0x000000xx = Connection unavailable
0x000000xx = Connection dropped by far end
0x000000xx = Connection Pending
- Null: no call exists 7. IANA Consideration
- 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 This draft requires the use of a number of new messages, TLVs, and
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 status codes from the number spaces within the LDP protocol.
- Release Request: this state exists when the client has requested the The two new messages (sections 5.2.9 and 5.2.10) and the eight new
network to clear the end-to-end lightpath, i.e. the client sending the TLVs (sections 5.1.1 to 5.1.8) should be considered as part of LDP
Label Release Message. base protocol and be assigned message and TLV types accordingly as
- Release Indication: this state exists when the client has received an outlined in [8]. All the values given in this draft should be
disconnect indication because the network has already disconnected the interpreted as advisory. There does not exist a preference to what
lightpath, i.e. when the client receives the Label Release Message. values should be used.
Similar connection states exist at the network side of the interface. Aboul-Magd Expires January 2002 22
The Status codes for the lightpath states are:
0x0000100C = Null Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
0x0000100D = Call Initiated
0x0000100E = Call Present
0x0000100F = Active
0x00001010 = Release Request
0x00001011 = Release Indication
7. Security Considerations The authors' current understanding is that MPLS status codes are not
sub-divided into specific ranges for different types of error. Hence,
the numeric status code values assigned for this draft should simply
be the next available values at the time of writing and may be
substituted for other numeric values. See section "Status Codes" for
details of the status codes defined in this draft.
This security mechanisms defined in [2] shall be used. 8. Security Considerations
8. Author's Addresses This draft doesn't introduce any new security issues other than
those in [8].
Osama S. Aboul-Magd Raj Jain 9. References
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 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
ONI Systems Corp. Tellium, Inc. 9, RFC 2026, October 1996.
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 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Laurel Networks Lucent Technologies Levels", BCP 14, RFC 2119, March 1997
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 3 B. Rajagopalan, "IP over Optical Networks: A Framework", draft-
ietf-ipo-framework-oo.txt, work in progress, July 2001.
Aboul-Magd April 2001 16 4 Mayer, M. Ed., "Requirements for Automatic Switched Transport
Draft-ietf-mpls-ldp-optical-uni-00.txt October 2000 Networks (ASTN)", ITU G.807/Y.1301, V1.0, May 2001.
Sorrento Networks 5 Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling
9990 Mesa Rim Road Functional Description", draft-ietf-mpls-generalized-signaling-
San Diego, CA 92121 04.txt, work in progress, May. 2001
Phone: 858-646-7195
Email: zzhang@sorrentonet.com
Full Copyright Statement 6 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP
Extensions", draft-ietf-mpls-generalized-cr-ldp-03.txt, work in
progress, May 2001
"Copyright (C) The Internet Society (date). All Rights Reserved. This 7 Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE
document and translations of it may be copied and furnished to others, Extensions", draft-ietf-mpls-generalized-rsvp-te-03.txt, work in
and derivative works that comment on or otherwise explain it or assist progress, May 2000.
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 8 Anderson, L., et. al., "LDP Specification", RFC 3036, January
2001.
1 Aboul-Magd, O. et. al., "Signaling Requirements at the IP-Optical 9 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0
Interface (UNI)" draft-ip-optical-uni-signaling-00.txt, work in Signaling Specifications", OIF Contribution, OIF2000.125.5, June
progress, July 2000. 2001
2 Andersson, L., et. al., "LDP Specifications÷, draft-ietf-mpls-ldp- 10 Jamoussi, B., "Constraint-Based LSP Setup using LDP", draft-ietf-
08.txt, work in progress, June 2000 mpls-cr-ldp-04.txt, work in progress, July 2000.
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Aboul-Magd Expires January 2002 23
Levels", BCP 14, RFC 2119, March 1997
4 Ashwood-Smith, P. et. Al., "Generalized MPLS - Signaling Functional Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
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- 10. Author's Addresses
crlsp-modify-01.txt, work in progress, Feb. 2000.
6 Fox, B. and Gleeson, B., ˘VPN Identifiers÷, IETF RFC-2685, Sept. Osama S. Aboul-Magd
1999. Nortel Networks
P.O. Box 3511, Station ˘C÷
Ottawa, Ont, K1Y-4H7
Tel : 613-763-5827
e.mail :osama@nortelnetworks.com
7 Jamoussi, B. Editor, ˘Constraint-Based LSP Setup Using LSP÷, draft- Sandra Ballarte
ietf-mpls-cr-ldp-04.txt, work in progress, July 2000. Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y-4H7
Phone: 613-763-9510
Email: ballarte@nortelnetworks.com
Aboul-Magd April 2001 17 Ewart Tempest
Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y-4H7
Phone: 613-768-0610
Email: ewart@nortelnetworks.com
Raj Jain
Nayna Networks, Inc.
157 Topaz St.
Milpitas, CA 95035
Phone: 408-956-8000x309
Fax: 408-956-8730
Email:raj@nayna.com
Liangyu Jia
ONI Systems Corp.
166 Baypoints Parkway
San Jose, CA 95134
Tel: 408-965-2743
Fax: 408-965-2660
e.mail:ljia@oni.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
Ocean Port, NJ 07757
Email :braja@tellium.com
Robert Rennison
Laurel Networks
2607 Nicholson Road
Sewickley, PA 15143, USA
Tel: +1 724-933-7330
Email:robren@laurelnetworks.com
Aboul-Magd Expires January 2002 24
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
Yangguang Xu
Lucent Technologies Inc.
21-2A41
1600 Osgood St.
N. Anderson, MA 01845
Tel : 978-960-6105
e.mail :xuyg@Lucent.com
Zhensheng Zhang
Sorrento Networks
9990 Mesa Rim Road
San Diego, CA 92121
Tel: 858-646-7195
e.mail:zzhang@sorrentonet.com
Aboul-Magd Expires January 2002 25
Draft-ietf-mpls-ldp-optical-uni-01 July, 2001
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 implmentation 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
Aboul-Magd Expires January 2002 26
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/