Specification of a Subset of CR-LDP
for Hardware Implementation
Tao Li, Zhifeng Tao, Haobo Wang, Malathi Veeraraghavan
Polytechnic University
tli@photon.poly.edu, jefftao@photon.poly.edu, haobo_w@photon.poly.edu,
mailto:mv@poly.edu
1. Introduction ..................................................................................................................... 1
2. Background ..................................................................................................................... 3
3. Our architecture and applications ................................................................................... 5
3.1 Architecture............................................................................................................... 5
3.2 Applications .............................................................................................................. 7
4. Subset specification for the hardware signaling module ................................................ 9
4.1 Procedures ................................................................................................................. 9
4.2 LDP messages ......................................................................................................... 10
4.2.1 LDP PDU [8] .................................................................................................. 11
4.2.2 Label Request Message [3][4][5][7][8] .......................................................... 12
4.2.3 Label Mapping Message [3][4][5][7][8] ......................................................... 14
4.2.4 Label Withdraw Message [3][4][5][7][8] ....................................................... 15
4.2.5 Label Release Message [3][4][5][7][8] ........................................................... 15
4.3 LDP TLVs ............................................................................................................... 16
4.3.1 General description of TLV [8] ...................................................................... 16
4.3.2 FEC TLV [8] ................................................................................................... 16
4.3.3 LSPID TLV [7] ............................................................................................... 18
4.3.4 Generalized Label Request TLV [4] ............................................................... 19
4.3.5 Traffic Parameter TLV [3] .............................................................................. 19
4.3.6 Hop Count TLV [8] ........................................................................................ 21
4.3.7 Preemption TLV [7] ........................................................................................ 22
4.3.8 Generalized Label TLV [3] ............................................................................. 22
4.3.9 Label Request Message ID TLV [8] ............................................................... 23
4.3.10 Interface ID TLV [4][5] ................................................................................ 23
5. Summary ....................................................................................................................... 24
1. Introduction1
Signaling protocols in switches are primarily implemented in software for two
reasons. First, signaling protocols are quite complex with many messages, parameters and
procedures. Second, signaling protocols are updated often requiring a certain amount of
flexibility for upgrading field implementations. While these are two good reasons for
implementing signaling protocols in software, there is an associated performance penalty.
1
This work is sponsored by a NSF grant, 0087487, and by NYSTAR (The New York Agency of Science,
Technology and Academic Research) through the Center for Advanced Technology in Telecommunications
(CATT) at Polytechnic University.
1
Even with state-of-the-art processors, software implementations of signaling protocols
are rarely capable of handling over 1000 calls/sec. Correspondingly, call setup delays per
switch are in the order of milliseconds. Applications of connection-oriented networks are
limited by this call setup overhead.
The goal of this project is to implement a signaling protocol, or at least a part of the
protocol, in hardware to decrease call setup delays and increase call handling
throughputs. In [1], we defined a signaling protocol for Synchronous Optical NETwork
(SONET) networks and implemented it in reconfigurable hardware, i.e., Field
Programmable Gate Arrays (FPGAs). These devices are a compromise between generalpurpose processors at one end of the flexibility-performance spectrum, and Application
Specific Integrated Circuits (ASICs) at the opposite end of this spectrum. FPGAs can be
reprogrammed with updates as signaling protocols evolve while significantly improving
call handling capacities relative to software implementations. Since signaling protocols
are very complex, our approach is to only implement the basic and frequently used
operations of the signaling protocol in hardware, and relegate the complex and
infrequently used operations (for example, processing of optional parameters, error
handling, etc.) to software.
When we defined our signaling protocol for SONET networks [1] in 1999, the
Generalized MultiProtocol Label Switching (GMPLS) effort in the IETF was just getting
underway. Now the GMPLS working group has generated many specifications [2]-[6].
Among these specifications are adaptations of Constraint Routing based Label
Distribution Protocol (CR-LDP) [7], which is itself an extension of the Label Distribution
Protocol (LDP) [8], and Resource reSerVation Protocol (RSVP). Since these signaling
protocols are much more complex than the one we defined in [1], and will be deployed in
the predictable future, we are currently undertaking a hardware implementation of one of
these protocols, i.e., CR-LDP with SONET/SDH extensions.
Of the two GMPLS signaling protocols specified, CR-LDP and RSVP-TE, we choose
CR-LDP with no specific reason. Both CR-LDP and RSVP-TE are similar and either can
be selected to demonstrate the feasibility of hardware implementation.
As stated earlier, given the complexity of these signaling protocols, it is not feasible to
implement these protocols in a “pure” hardware based design. Instead, we propose
implementing only a subset of the protocol in hardware and the remaining portion in
software for execution on a general-purpose processor. To achieve high performance, we
need to select specific messages and parameters carefully so that a high percentage of
signaling messages can be handled by the hardware module. This design document
describes a subset of CR-LDP for our hardware implementation.
Section 2 provides background on GMPLS signaling. Section 3 describes our target
architecture and applications, for which we specify a subset of CR-LDP for hardware
implementation. This subset specification is described in section 4. Section 5 summarizes
this paper.
2
2. Background
The GMPLS architecture is defined in [2]. GMPLS extends MultiProtocol Label
Switching (MPLS), which is designed for packet switching, to other types of switching,
such as time-division, wavelength-division, and space-division switching. The GMPLS
signaling specifications are based on RSVP-Traffic Engineering (RSVP-TE) and CRLDP signaling. The GMPLS signaling specification consists of a signaling functional
description[4], CR-LDP extensions[5] and RSVP-TE extensions[6]. In addition, there are
technology-specific extensions such as GMPLS extensions for SONET and Synchronous
Digital Hierarchy (SDH) control[3][9], and GMPLS extensions for G.709 control[10].
Of all the signaling procedures allowed by MPLS, only a subset is applicable to
GMPLS networks[2]:

Downstream-on-demand label allocation and distribution

Ordered control

Liberal (typical), and conservative label retention mode

Request, traffic/data, and topology driven label allocation strategies

Explicit routing (typical), and hop-by-hop routing
Before describing these procedures, we define the terms “downstream” and
“upstream.” Since connections 2 are unidirectional, a switch SW1 is an “upstream”
neighbor of another switch SW2 if data flows from SW1 to SW2 on the connection after it
is established. Likewise, SW2 is a “downstream” neighbor of SW1.
In downstream-on-demand label allocation mode, a switch does not allocate a label
unless its upstream neighbor explicitly requests a label. This is in contrast to downstreamunsolicited label allocation mode where a switch can initiate the allocation and
distribution of a label without being explicitly asked to do so. In GMPLS, only the former
procedure is allowed.
Ordered control implies that a switch does not allocate labels for a connection until it
has an established label leading to the destination in question on its downstream side. In
other words, connection setup proceeds switch-by-switch with Label Request Messages
flowing from upstream switches toward their downstream neighbors, and Label Mapping
Messages flowing in the reverse direction as shown in Figure 1. This mode of control is
in contrast to independent control where switch SW2 can allocate a label in response to a
Label Request Message from an upstream switch even if the connection is not established
downstream of switch SW2. GMPLS requires the use of ordered control.
2
We use the generic term “connections” interchangeably with the term “Label Switched Paths (LSPs).”
3
Figure 1: Ordered control
The label retention mode has to do with whether or not a connection to a destination D
is retained even when there is a change in the routing data for D. To set up a connection,
routing data is consulted with the destination address of the connection to obtain a nexthop address toward which to route the connection. Furthermore, resources are allocated
and labels are assigned for the connection. Following such a setup if the routing data for
the connection changes, indicating an alternate path to the destination than the one used
while setting up the connection, in liberal label retention mode, the connection stays
established until explicitly released, whereas in conservative label retention mode, the
connection is released on the old path and reestablished via the new next hop node. With
ordered control, we assume that the choice of label retention mode should be made at the
end nodes of a connection rather than in all transit nodes.
Label allocation strategies are concerned with how a connection setup is initiated. The
request strategy is based on the reception of an explicit request. A traffic driven strategy
is used when an IP router or other type of node measures traffic being sent on a certain
route and decides when to initiate the set up of a connection. A topology driven strategy
is used when an IP router or other type of node detects a need to change the topology of
the network at the IP layer and initiates the set up of a connection. Topology changes in
the connection-oriented network, such as link failures, could trigger a reestablishment of
connections.
Finally, the type of routing used can be explicit or hop-by-hop. In explicit routing, the
ingress switch determines the end-to-end route and places this as a parameter in the Label
Request Message. This is referred to as “source routing” in the general literature. In
contrast, with hop-by-hop routing, each switch determines the next-hop switch toward
which to route a connection. Both modes are allowed in GMPLS networks.
The GMPLS signaling specifications define the following eleven new features for
supporting switching technologies other than packet switching [2]:
1. A new generic label request
2. Labels for Time Division Multiplex (TDM), Lambda Switch Capable (LSC) and
Fiber-Switch Capable (FSC) interfaces, generically known as Generalized Labels
3. Waveband switching support
4. Label suggestion by the upstream node for optimization purposes
5. Label restriction by the upstream node to support some optical constraints
4
6. Bi-directional Label Switched Path (LSP) establishment
7. Rapid failure notification extensions
8. Protection information currently focusing on link protection, plus primary and
secondary LSP indication
9. Explicit routing with explicit label control for a fine degree of control
10. Technology-specific traffic parameters
11. LSP administrative status handling
GMPLS is highly generic since it caters to a wide-variety of networks, both packetand circuit-switched, and hence has many options. Only building blocks 1, 2 and 10 are
mandatory. Typically building blocks 6 and 9 should be implemented. Building blocks 3,
4, 5, 7, 8 and 11 are optional.
The GMPLS signaling used in a typical SDH/SONET switching network would
include building blocks 1, 2, 6, 9, 10 and 11. Since SDH/SONET switching network has
already implemented protection and restoration functions, building blocks 7 and 8 are
optional[2].
3. Our architecture and applications
As described in Section 2, there are many versions of LDP: basic LDP, CR-LDP, CRLDP for GMPLS networks, GMPLS CR-LDP with extensions for SONET/SDH, etc.
This complex protocol is now targeting almost all connection-oriented networks both
packet-switched and circuit-switched. This drive impacts most of the fields in parameters
within messages. For example, the specification of the address field identifying the
destination address of the connection allows for different address families, IPv4, IPv6,
telephony E.164, ATM End System Addresses, etc. This is just one example. A majority
of the fields can be assigned different values depending on the specific architecture and
applications being targeted. This goal of developing a “flexible” signaling protocol thus
operates against our goal of implementing a high-performance signaling engine.
Our solution to this problem is to define a subset of the signaling protocol for
hardware implementation based on a specific target architecture and applications. In this
section, we define our target architecture and applications.
3.1 Architecture
Our target switch is a SONET switch operating at an STS-1 cross-connect rate. The
reason we choose SONET switches to demonstrate our high-performance signaling
engine is as follows. First, we decided to use a circuit switch instead of a packet switch
because signaling protocol messages for Circuit-Switched (CS) networks carry fewer
parameters than for Connection-Oriented (CO) Packet-Switched (PS) networks. For
example, signaling messages for CO PS networks carry rate information and burstiness
parameters in the traffic descriptor, and delay and loss requirements, while in CS
networks, signaling messages only carry a peak (or constant) rate traffic descriptor.
Second, among the various circuit switches available, we eliminated optical WDM
5
switches even though they have the advantage of bit-rate transparency, because optical
circuit switches, such as MicroElectro-Mechanical Systems (MEMS) based switches,
typically have long switch programming times (in the order of a few ms) [11]. This
explains our choice of (electronic) SONET switches.
In our architecture, control channels are distinct from the user data links. We assume
that the control channels between switches are 1Gbps Ethernet (GbE) links. The reason
for this assumption is as follows. Since our goal is to demonstrate a low call setup delay,
using lower-speed signaling links will result in higher emission delays for signaling
messages. Therefore, we plan on using 1GbE links for the signaling links. This means a
common control channel carries signaling messages for all interfaces between two
switches.
Figure 2 illustrates the switch architecture. The user-plane line cards and switch fabric
constitute a SONET switch. The signaling engine shown in the control-plane unit has a
Hardware signaling module, which will be implemented in reconfigurable hardware such
as FPGA, and a Software signaling process, which is a process running on a generalpurpose microprocessor. Other software processes such as the illustrated Routing process
will be needed. Maintenance and management software is omitted for clarity from Figure
2. The input and output signaling interfaces are GbE links.
Figure 2: Unfolded view of a switch
The network architecture consists of many SONET switches. We allow for multiple
SONET interfaces between two SONET switches. The network can have an arbitrary
topology. The endpoints of this network that generate requests for circuits are allowed to
be IP routers or end hosts with IP addresses assigned to their SONET interfaces. Thus,
the only addressing scheme supported is IPv4. We allow for non-neighboring SONET
switches to be logically connected with “fat” pipes that traverse intermediate switches as
illustrated in Figure 3.
6
End
Device 1
SW2
SW1
SW3
SW6
End
Device 2
SW5
SW4
The LSP between End Device 1 and End Device 2
Physical Link
Traffic Engineering Link ("fat pipe")
SW#
SONET
Switch
Figure 3: Network architecture
3.2 Applications
We target this specification of the CR-LDP subset for two applications. The first
application is restoration in a SONET ring. When a failure occurs, the ends of paths
traversing the failed link detect the failure through signals such as path-AIS (Alarm
Indication Signal) and initiate restoration procedures. All restoration is on unidirectional
circuits. For example, if the ring is a Unidirectional Line Switched Ring (ULSR), then
typically only one direction of the circuits need to be restored after the first failure (in the
example shown in Figure 4, only the 4-3 circuit needs restoration when the span from 1
to 2 fails, while the 3-4 circuit is intact). In the case of a Bidirectional Line Switched
Ring (BLSR), circuits will be lost in both directions. However, with this choice of the
CR-LDP subset, the circuit in each direction is restored with a separate set of signaling
messages.
Figure 4 shows an example ULSR. If the span from node 1 to 2 fails, then router 4 will
initiate the restoration of the circuits from 4 to 2 and 4 to 3. Router 1 will initiate
restoration of the circuits from 1-2, 1-3 and 1-4. Router 3 will initiate restoration for the
circuits from 3-2. Thus the sending end of the unidirectional circuits sends the initiating
Label Request Message. This allows for it to start sending data when it receives the Label
Mapping Message after the ordered downstream-on-demand setup.
7
R1
ADM1
ADM2
ADM4
R2
ADM3
R4
R3
Figure 4: Ring restoration application
The second application is for file transfers. We assume that the client and server hosts
are connected by two types of end-to-end paths: a TCP/IP path and an end-to-end
SONET circuit as shown in Figure 5. In this application, the client opens a TCP
connection on the IP network and sends a URL (if http is the application layer protocol)
or a get request (if ftp is the application layer protocol). The server decides whether to
send the file on the TCP/IP path or whether to set up a SONET circuit for the file transfer.
This decision could be based on the size of the file to be transferred, the availability of an
end-to-end SONET path to the client, etc. If the server decides to use a SONET circuit, it
generates a Label Request Message to a downstream node leading to the client. Again the
downstream node should send another Label Request Message to the next hop in its
routing table. Label Request Messages are sent switch-to-switch from the server to the
client in such a way. The client responds with a Label Mapping Message to the node
from which the client receives the Label Request Message. Label Mapping Messages are
sent switch-to-switch from the client to the server. The server starts data flow once it
receives the Label Mapping Message. Thus the sending end of the unidirectional circuit
is the initiator of the Label Request Message.
For releasing a connection, the client initiates the release after it has received the
whole file. It sends a Label Withdraw Message; this works well with the LDP
specification in which the downstream Label Switched Router (LSR) is the one that
initiates label withdrawal.
8
TCP/IP path
SONET circuit
Server
Client
LEGEND
IP Router
CO
Switch
Figure 5: File transfers between the Server and Client
4. Subset specification for the hardware signaling module
In this section, we identify a subset of GMPLS CR-LDP signaling for SONET
networks that will be implemented in reconfigurable hardware. This includes procedures,
messages and parameters.
4.1 Procedures
Our subset specification for the hardware signaling module is only for a transit switch
signaling engine implementation. It does not include the implementation needed in “user”
ends of a connection. By “user” ends, we mean the terminating nodes of connections,
e.g., end hosts, IP routers or other network nodes. This has implications in choosing
specific options for the GMPLS procedures that have multiple options as listed in Section
2.
Of these procedures, the first two, label allocation and type of control, have only one
option for GMPLS, i.e., downstream-on-demand label allocation and ordered control.
Therefore, we implement these mandatory options. On the third and fourth procedures, in
the subset of the signaling engine implemented in hardware, we implement the liberal
retention mode, i.e., it does not initiate the rerouting of an established connection to a
destination D if the routing data to destination D changes. The software signaling process
can support both retention modes; in the conservative mode, it would monitor changes in
the routing data and initiate rerouting of established LSPs. Release of established
connections is only executed by the hardware signaling module only with an explicit
Label Withdraw Message. Similarly, the hardware signaling module only executes
request driven label allocation strategy in that it does not monitor topology changes or
9
traffic to initiate label allocations. Such operations are left to the software signaling
process. On the last procedure, type of routing, we choose to only implement hop-by-hop
routing in the hardware signaling module because of the complexity involved in parsing
parameters related to explicit routing. If a Label Request Message is received with an
Explicit Route parameter, then the message will be handled by the software signaling
process.
For the hardware signaling module, we only adopt building blocks 1, 2 and 10 of the
set of features developed for GMPLS (listed in Section 2). These are handling the new
generic label request, the Generalized Label, and SONET-specific traffic parameters. The
rest of the features are left for the software signaling process.
The hardware signaling module will only implement the hop count based loop
detection procedure. If a signaling message contains a path vector, this is handled by the
software signaling process.
The software signaling process implements:

LDP peer discovery and neighbor maintenance

LDP session initialization and maintenance

Connection setup when it can not be handled by the hardware signaling module

Connection release when it can not be handled by the hardware signaling module

Management-plane related functions, such as downloading routing data and
initializing the hardware signaling module
The hardware signaling module implements basic connection setup and release.
4.2 LDP messages
There are 11 LDP message types [8], out of which we choose a subset of 4 messages
for hardware implementation. Label Request and Label Mapping Messages are used to
set up an LSP. Label Release and Label Withdraw Messages are used to release an LSP.
Other messages are used for initialization or notification purposes and are thus used less
frequently than these four messages.
In describing the messages and parameters, we list acceptable values for fields and
actions taken in the hardware signaling module. By default, if a field contains a value
other than those listed, the message is passed off to the software signaling process for
processing.
All LDP messages have format as follows.
U bit (1bit)
Message Type (15 bits)
Message Length (16 bits)
Mandatory Parameters
Optional Parameters
Based on specifications of LDP [8], CR-LDP [7], GMPLS extensions to CR-LDP [5]
and GMPLS extensions for SONET and SDH control [3], we include all mandatory
parameters and choose some optional parameters according to our intended applications.
10
4.2.1 LDP PDU [8]
LDP message exchanges are accomplished by sending LDP Protocol Data Units
(PDUs) over TCP connections. Each LDP PDU can carry one or more LDP messages.
Messages in an LDP PDU need not be related to one another. For example, a single PDU
could carry a Label Request Message for one LSP, a Label Mapping Message for another
LSP, and a third message requesting label release. Each LDP PDU has an LDP header
followed by one or more LDP messages. The format of the LDP header is specified in [8]
as follows.
Version (0~15 bit)
PDU length (16~31 bit)
LDP Identifier
Version: The Version field is negotiated in session initialization. After session
initialization, the software signaling process should pass this parameter off to the
hardware signaling module.
Hardware signaling module behavior:
Version
Hardware signaling module behavior
0x1
Accept
Other value
Pass off to the software signaling process
PDU Length: This field is used to specify the total length of PDU in octets, excluding
Version and PDU Length fields. The maximum allowable length is negotiable when an
LDP session is initialized. Prior to completion of the negotiation the default maximum
allowable length is 4096 bytes.
Hardware signaling module behavior: The hardware signaling module should use this
field to find the boundary of a LDP PDU.
LDP Identifier: Six octets field that uniquely identifies the sending LSR and its label
space for which this PDU applies. The first four octets identify the LSR and must be a
globally unique value. It should be a 32-bit router ID assigned to the LSR. This ID can
also be used to detect loops when parsing Path Vectors. The last two octets identify a
label space within the LSR. An LSR can have per-interface significance, as with ATM
Virtual Path Identifier/Virtual Channel Identifiers (VPI/VCIs), or per-platform
significance. The LDP Identifier field is negotiated in session initialization. After session
initialization, the software signaling process should pass valid values for this parameter to
the hardware signaling module.
Hardware signaling module behavior: The hardware signaling module should compare
this field with the corresponding values received from the software signaling process
during initialization to check its validity.
11
4.2.2 Label Request Message [3][4][5][7][8]
A Label Request Message is used by an upstream LSR to ask a downstream LSR to
“allocate a label” to reach a destination [8]. More generally, it is a request to set up a
connection.
There are four mandatory Type-Length-Value fields (TLV3), as shown in the format of
the message below, among which the Generalized Label Request TLV and the Traffic
Parameter TLV are chosen according to GMPLS extensions for SONET networks. Of all
optional parameters, the Hop Count TLV is chosen for detecting loops, which can occur
when hop-by-hop routing is used. The other two optional TLVs chosen for hardware
signaling module processing are described below.
The format of a Label Request Message handled by the hardware signaling module:
U:0x0
Message Type (0x401)
Message Length
Message ID
FEC TLV (up to 12 bytes, mandatory in LDP [8])
LSPID TLV (12 bytes, mandatory in CR-LDP [7] )
Generalized Label Request TLV (8 bytes, mandatory in GMPLS CR-LDP [5])
Traffic parameter TLV (12 bytes, mandatory in [2])
Interface ID TLV (12 byte, optional)
Hop Count TLV (8 bytes, optional)
Preemption TLV (8 bytes, optional)
The Interface ID TLV is used to identify links. This becomes necessary when the
control plane links are separate from the user data links and there could be multiple
interfaces between two SONET switches. Even though as described in Section 2, the
connection setup messages flow from the upstream switches toward the downstream
switches and downstream switches are the ones that select labels, the GMPLS signaling
specification document [4] states that the upstream switch selects the Interface ID. If
there are multiple interfaces between two switches, since the downstream switch allocates
labels, it should be the one that chooses an interface with available labels. However,
because of the statement in [4] that the upstream switch selects the Interface ID, we
included the function of processing this TLV in the hardware signaling module.
The Preemption TLV is used to provide priority. An LSP request with a higher priority
should be allowed to preempt established LSPs with lower priorities. We felt that this
option may be exercised often in circuit-switched networks, such as SONET, where the
level of sharing is only at the call-level. Hence the likelihood of all circuits being busy
when a new call arrives could be higher than in connection-oriented packet-switched
networks where a second level of sharing, at the packet level, is allowed. Hence, we
included the Preemption TLV for processing by the hardware signaling module.
The term “TLV” is used interchangeably with the term “parameter” even though TLV is just a
representation format for parameters.
3
12
Of all other optional TLVs, the Path Vector TLV is omitted in the subset for hardware
implementation due to its complexity, especially given its variable length. The Explicit
Route TLV is omitted for a similar reason. Finally, the Route Pinning TLV is not
included because route pinning is the default mode for all LSPs. Label Request Messages
carrying any of these TLVs will be handled by the software signaling process.
The maximum length of a Label Request Message processed by the hardware
signaling module is 80 bytes. If the message length exceeds 80 bytes, the whole message
should be passed off to the software signaling process.
Notes:

There is no alignment requirement for the first byte of a PDU/Message/TLV.

The TLVs can appear in any order.

If a TLV other than those shown in the message format below is found, the
whole Label Request Message should be passed off to the software signaling
process.

If any mandatory TLV shown in the message format below is missing, the
whole Label Request Message should be passed off to the software signaling
process.
Example
0~7 bit
0
8~15 bit
16~23 bit
Message type: 0x401
24~31 bit
Message length: 0x
Message ID
U:0x0
F:0x0
Type: FEC (0x100)
Parameter length: 0x
Type: 0x821
Length: 0x41
FEC Element
U:0x0
F:0x0
Reserved: (0x0 12bit)
ActFLg
Local CR-LSP ID
Ingress LSR Router ID
U:0x0
F:0x0
Type: to be announced
LSP Enc. Type: 0x6 (assume
SONET)
U:0x0
F:0x0
Switching Type
Type: 0xTBA
Length: 0x4
G-PID
Length: 0x12
Traffic parameter for SONET
Signal Type
RCC
NVC
NCC
Multiplier (MT)
Transparency (T)
U:0x0
F:0x0
Type: 0x103
Hop count value
U:0x0
F:0x0
Length: 0x4
Reserved: 0x0
Type: 0x820
Length: 0x4
13
Set priority: 0x4
Hold priority: 0x4
Reserved: 0x0
4.2.3 Label Mapping Message [3][4][5][7][8]
The Label Mapping Message is used for a downstream LSR to advertise the binding of
a label to a destination address. It is sent after resources are reserved and a connection is
established through a switch, mapping incoming labels to outgoing labels. It carries the
labels assigned to the connection from the downstream switch to the upstream switch.
There are three mandatory TLVs, as shown in the format below. Of all optional TLVs,
the Interface ID TLV is chosen for hardware processing under the assumption that in
many instances, two neighboring switches may be interconnected with multiple
interfaces, making this TLV common in Label Mapping Messages. The LSPID TLV is
not necessary but included since the hardware signaling module anyway needs to
implement the processing of this TLV for Label Request Messages (in which this TLV in
mandatory). The Hop Count TLV is included for the same reason as in the Label Request
Message.
The only omitted optional TLV for Label Mapping messages is the Path Vector TLV.
Its omission is for the same reason as in the Label Request Message.
Format:
U
Label Mapping (0x400)
Message Length
Message ID
FEC TLV (up to 12 bytes, mandatory in LDP [8])
Generalized Label TLV (variable, could be 8/12/16/… bytes, mandatory in GMPLS CR-LDP [5])
Label Request Message ID TLV (8 bytes, mandatory in CR-LDP [7])
Interface ID TLV (12 byte, optional)
LSPID TLV (12 bytes, optional)
Hop Count TLV (8 bytes, optional)
Example:
0~7 bit
0
8~15 bit
Message type: 0x400
16~23 bit
24~31 bit
Message length: 0x
Message ID
U:0x0
F:0x0
Type: FEC (0x100)
Parameter length: variable
Type: TBA
Length: 0x4
FEC element
U:0x0
F:0x0
Variable (32 bit is enough in our case)
14
U:0x0
F:0x0
Type: 0x0600
Length: 0x4
Label Request Message ID
U:0x0
F:0x0
Length: 0x41
Type: 0x821
Reserved: (0x0 12bit)
ActFLg
Local CR-LSP ID
Ingress LSR Router ID
U:0x0
F:0x0
Type: 0x103
Hop count value
Length: 0x4
Reserved: 0x0
4.2.4 Label Withdraw Message [3][4][5][7][8]
The Label Withdraw Message is used to request the release of an LSP. This message
is sent by a downstream LSR to a upstream LSR because it is the one that assigned the
labels. Other than the mandatory FEC TLV, we include three optional TLVs for hardware
implementation as shown in the format below. The Interface ID TLV and Generalized
Label TLV are used to identify the time slots of an LSP to be released. The LSPID TLV
is included for the same reason described in Section 4.2.3.
Format:
0
Message Type (0x402)
Message Length
Message ID
FEC TLV (up to 12 bytes, mandatory in [8])
Interface ID TLV (12 byte, optional)
Generalized Label TLV (variable size, optional)
LSPID TLV (12 bytes, optional)
4.2.5 Label Release Message [3][4][5][7][8]
The Label Release Message is used for an upstream LSR to ask or confirm the release
of an LSP. An upstream LSR could send out a Label Release Message with or without
receiving a Label Withdraw Message from a downstream LSR. The choice of TLVs is
similar to that in the Label Withdraw Message as shown below.
Format:
0
Message Type (0x403)
Message Length
Message ID
FEC TLV (up to 12 bytes, mandatory in [8])
Interface ID TLV (12 byte, optional)
Generalized Label TLV (variable length, optional)
LSPID TLV (12 bytes, optional)
15
4.3 LDP TLVs
LDP uses the TLV encoding scheme for the information carried in LDP messages.
The advantage of the TLV structure is that it allows parameters to be listed in any order
in a message, which, in turn, allows for parameters to be redefined, new parameters to be
added, etc. This is unlike the fixed structure for fields used in the definition of headers for
most standard protocols, such as IP, ATM, etc. The cost of this flexibility however is in
performance. Processing of LDP messages in hardware becomes more difficult because
of this TLV structure.
There are mandatory TLVs, optional TLVs and user-defined TLVs. We include all the
mandatory TLVs of LDP, CR-LDP and GMPLS. Certain optional TLVs are selected for
the reasons described in Section 4.2. The values of TLV fields are selected according to
the specifications, the choice of switching technology (SONET), and our applications.
4.3.1 General description of TLV [8]
An LDP TLV is encoded as a 2-byte field that uses 14 bits to specify a Type and 2 bits
to specify behavior when an LSR does not recognize the Type, followed by a 2-byte
Length field, followed by a variable length Value field [8].
0~15 bit
U
F
16~31 bit
Type
Length
Value
The U bit and F bit regulate the behavior of the signaling processor when an unknown
type TLV is received. Since the whole message will be passed off to the software
signaling process if an unknown TLV exists, the hardware signaling module will not
process these two bits.
Type: Indicates the type of the TLV.
Hardware signaling module behavior: If the value of type field is unknown, the whole
message should be passed off to software.
Length: Specifies the length of the Value field in octets.
Hardware signaling module behavior: Use this field to find the next TLV.
Value: The content of TLV.
4.3.2 FEC TLV [8]
The purpose of this Forwarding Equivalence Class (FEC) TLV is to indicate the
address of the destination of the connection. The FEC TLV is mandatory in LDP, and
because all subsequent versions of LDP, such as CR-LDP, inherit the basic constraints of
LDP, all CR-LDP messages for SONET networks must carry this TLV.
16
Labels are bound to destinations, i.e., a label is associated with a FEC. A FEC is a list
of one or more FEC elements. Since in our applications (see Section 3.2), we use IPv4 as
the addressing scheme, the hardware signaling module only handles this type of address.
U
F
Type: FEC (0x100)
Parameter length: 0xVariable
FEC Element 1
FEC Element 2
…
Multiple FEC elements may be present in a Label Withdraw Message asking for the
release of all LSPs related to those FEC elements. If multiple FEC elements are found,
the whole message should be passed off to the software signaling process.
Parameter length: Length is variable depending on the FEC element type.
FEC element type
Possible length
Hardware signaling module behavior
Prefix
0x4, 0x5, 0x6, 0x7, 0x8
process
Full host address
0x8
process
other
Pass to software
A FEC Element includes a 1-octet type field, and a variable length field that is the
type-dependent element value. There are several types of FEC elements. The FEC
element encoding depends on the type of the FEC element.
FEC Element
FEC Element type
FEC Element value
FEC Element type: This field should be either 0x2 or 0x3. If other value is found,
whole message should be passed off to the software signaling process.
FEC Element type value
Type
Hardware signaling module behavior
0x2
Prefix
process
0x3
Full host address
process
Other value
Pass to software
Prefix FEC Element encoding:
0-7 bit
Prefix: 0x2
8-23 bit
Address family
24-31 bit
PreLen:
Prefix
Address Family:
17
Address Family
Type
Hardware signaling module behavior
0x1
IP version 4
process
Other value
Pass off to the software signaling process
PreLen: One octet unsigned integer containing the length in bits of the address prefix
that follows. A length of zero indicates a prefix that matches all addresses (the default
destination); in this case the Prefix itself is zero octets. The PreLen could vary from 0x0
to 0x20.
Prefix: An address prefix encoded according to the Address Family field, whose
length, in bits, was specified in the PreLen field, padded to an octet boundary.
Host Address FEC Element encoding:
0-7 bit
8-23 bit
24-31 bit
Hostaddress: 0x3
Address family: 0x1
Host Addr Len
Host Addr
Host Addr Len: Length of the Host address in octets.
Host Addr: IPv4 address.
In other words, the hardware signaling module only processes FEC TLVs if they
contain only 1 IP address, either a prefix or a complete host address.
4.3.3 LSPID TLV [7]
The LSPID is a unique identifier of a CR-LSP within an MPLS network. The LSPID
is composed of the ingress LSR Router ID (or any of its interface IPv4 addresses) and a
Local CR-LSP ID, which is unique to that LSR. In other words, it is a global connection
reference.
U
F
Type: 0x821
Reserved: (0x0 12bit)
Length: 0x8
ActFLg
Local CR-LSP ID
Ingress LSR Router ID
ActFlg4 (Action Indicator Flag): A 4-bit field that indicates explicitly whether a Label
Request Message is an initial LSP setup request or a modification request.
4
The need for an ActFLg is somewhat unclear for the following reason. The Label Request Message is
used both for the modification of a connection and the setup of a new connection. If the LSPID indicated in
the Label Request Message is new, the transit switch receiving the Label Request Message could directly
interpret the message as requesting a new LSP setup. On the other hand, if the LSPID already exists at the
transit switch, the Label Request Message could be interpreted as an LSP modification. Therefore, the
ActFlg seems redundant unless it is justifiable for certain error conditions.
18

0000: indicates initial LSP setup

0001: indicates modify LSP (The hardware signaling module should pass the
whole message to the software signaling process)
If the ActFlg indicates that it is a new LSP setup, then the LSPID will be used to set
up a new connection. On the other hand, if it is a request for a bandwidth modification,
then the switch receiving the message should correlate it with the information it has
currently for the LSPID in question.
Local CR-LSP ID: The Local LSP ID is an identifier of the CR-LSP locally unique
within the Ingress LSR originating the CR-LSP.
Ingress LSR Router ID: An LSR may use any of its own IPv4 addresses in this field.
Hardware signaling module behavior: If the Type indicates LSPID TLV, check the
length; if the length is not 8, pass the message to the software signaling process.
Otherwise ignore the next 12 bits and then extract field ActFlg. If ActFlg field does not
equal to 0x0, the whole message should be passed off to the software signaling process.
4.3.4 Generalized Label Request TLV [4]
The Generalized Label Request TLV defines the characteristics of the requested LSP.
The software signaling process will download the appropriate values for the fields of this
TLV based on the type of switch served by the signaling engine.
U
F
Type: to be announced
LSP Enc. Type: 0x6
(assume SONET)
Length: 0x4
Switching Type: 0x100
G-PID
LSP Enc. Value
Type
Hardware signaling module behavior
6
SONET ANSI T1.105
Process
All others
Pass to the software signaling process
Switching Type: Value
Type
Hardware signaling module behavior
100
Time-Division-Multiplex
Process
other
Pass to the software signaling process
G-PID: An identifier of the payload carried by an LSP, i.e., an identifier of the client
layer of that LSP.
Hardware signaling module behavior: Does not process the G-PID field. This is
because we only are considering the signaling processor in transit nodes only. The G-PID
field should be transparent to all transit nodes.
4.3.5 Traffic Parameter TLV [3]
This TLV is used to specify the bandwidth requirement and any other requirements for
the requested LSP. The format of this TLV for SONET is as follows.
19
U
F
Type: 0xTBA
Length: 0x12
Traffic parameter for SONET
Signal Type
RCC
NVC
NCC
Multiplier (MT)
Transparency (T)
Signal Type (8 bits): This field indicates the type of the Elementary Signal of the
requested LSP. The Elementary Signal is used as basic building block for the Final Signal
required by the LSP. With the help of other fields, such as RCC, NCC, NVC, MT and
Transparency, the Final Signal is built based on the Elementary Signal. Permitted values
of Signal Type for SONET/SDH could be found in [3].
RCC (Requested Contiguous Concatenation, 8 bits): This field is used by an upstream
node to advertise all supported modes of contiguous concatenation to a downstream node.
The specific contiguous concatenation mode to be used is selected by the downstream
node. Only the first two bits of this field have been defined so far.

Flag 1 (bit 1): Standard contiguous concatenation.

Flag 2 (bit 2): Arbitrary contiguous concatenation.
NCC (Number of Contiguous Components, 16 bits): This field indicates the number of
identical SONET/SDH SPEs/VCs that are requested to be contiguously concatenated.
NVC (Number of Virtual Components, 16 bits): This field indicates the number of the
Elementary Signals that are requested to be virtually concatenated.
MT (Multiplier, 16 bits): This field indicates the number of identical signals that form
the Final Signal for the requested LSP. These signals can be identical Elementary
Signals, or identical contiguously concatenated signals, or identical virtually
concatenated signals. Note that all these fields specify the traffic parameters for one LSP.
Transparency (T, 32-bit): Only 12 bits are used now.
Flag 1 (bit 1): Section/Regenerator Section layer.
Flag 2 (bit 2): Line/Multiplex Section layer.
Flag 3 (bit 3): J0.
Flag 4 (bit 4): SOH/RSOH DCC (D1-D3).
Flag 5 (bit 5): LOH/MSOH DCC (D4-D12).
Flag 6 (bit 6): LOH/MSOH Extended DCC (D13-D156).
Flag 7 (bit 7): K1/K2.
Flag 8 (bit 8): E1.
Flag 9 (bit 9): F1.
Flag 10 (bit 10): E2.
Flag 11 (bit 11): B1.
20
Flag 12 (bit 12): B2.
The Final Signal carried in the LSP is built from the Elementary Signal through the
following steps and in the order shown below. Each step is optional and must be ignored
if the field referred at that step is zero. The only exception is that MT cannot be zero and
is ignored if equals to one.
First, a contiguously concatenated signal (specified by the RCC and NCC fields) is
built from the Elementary Signal.
Second, a virtually concatenated signal (specified by the NVC field) is obtained either
directly from the Elementary Signal, or from the contiguously concatenated signal
obtained from the previous phase.
Third, a transparency identification can be optionally specified when requesting a
frame as a signal rather than as an SPE or VC based signal (by using the Transparency
field).
Fourth, the Final Signal is obtained by a multiplication (specified by the Multiplier
field) of the Elementary Signal, or the contiguously concatenated signal obtained from
the first phase, or the virtually concatenated signal obtained from the second phase, or the
signals obtained after the combination with transparency.
Typical example: The 2xSTS-4a-5v signal is represented in a Traffic Parameter TLV
with an RCC value of 2 (for arbitrary contiguous concatenation), NCC value of 4, NVC
value of 5, MT value of 2 and T value of 0, with an STS-1 SPE Signal Type value. This
represents that there are 40 STS-1s in the requested LSP.
For our architecture (described in Section 3.1), where the switch operates at STS-1
cross-connect rate, the hardware signaling module and software signaling process will
only process messages in which the Signal Type of the Traffic Parameters TLV is STS-1.
4.3.6 Hop Count TLV [8]
This TLV is used for loop detection. Once hop count exceeds a preset value, it
indicates there is a loop.
U
F
Type: 0x103
Hop count value
Length: 0x4
Reserved: 0x0
A Hop Count TLV contains a count of the LSRs that the containing message has
traversed. When an LSR propagates a message containing a Hop Count TLV it increases
the count. An LSR detects a loop if the hop count reaches a configured maximum value.
By convention, a count of 0 is interpreted to mean the hop count is unknown.
Incrementing an unknown hop count value results in an unknown hop count value (0).
The maximum allowable hop count value should be set in the hardware signaling module
during initialization by the software signaling process.
21
4.3.7 Preemption TLV [7]
The Preemption TLV is used to provide priority. An LSP with higher priority should
be offered a higher probability of success by preempting lower priority LSPs.
U
F
Type: 0x820
Set priority: 0x4
Length: 0x4
Hold priority: 0x4
Reserved: 0x0
SetPrio: The value zero is used to indicate that the requested LSP has the highest
priority. The value of seven is used to represent the lowest priority. The higher the setup
priority, the more paths the CR-LDP engine can preempt to set up the new path. The
default value of this field should be 4.
HoldPrio: The value of zero is the highest priority could be assigned to a path. The
value of seven indicates that the path has the lowest priority. The default value of this
field should be 4. The higher the holding priority, the less likely it is for the CR-LDP
engine to reallocate its bandwidth to a new path.
CR-LDP signals the resources required by a path on each hop of the route. If a route
with sufficient resources can not be found, existing paths may be rerouted to reallocate
resources to the new path. This is the process of path preemption. Setup and holding
priorities are used to rank existing paths (holding priority) and the new path (setup
priority) to determine if the new path can preempt an existing path. Signaling a higher
holding priority expresses that the path, once it has been established, should have a lower
chance of being preempted. Signaling a higher setup priority expresses the expectation
that in the case that resources are unavailable, the signaling process engine is more likely
to preempt other paths.
Hardware signaling module behavior: The module records holding priority of
connection as they are set up but does not perform actual preemption when resources are
unavailable. Preemption is handled by the software signaling process. This is because of
the complexity involved in choosing a connection to preempt and initiating its release.
4.3.8 Generalized Label TLV [3]
This TLV defines a generalized format for the labels to be carried in Label Mapping
Messages. The type of label depends upon the type of switch. Each Generalized Label
TLV carries a variable length label parameter.
U
S
F
Type: TBA
Length: variable, multiple 0x4
U
K
L
M
U
K
L
M
…
S
For SONET, the U and K fields are not significant and must be set to zero. Only the S,
L and M fields are significant. If signal concatenation or multiplication is indicated in the
Traffic Parameter TLV, there may be several labels. For contiguous concatenation, only
22
the lowest Elementary Signal will appear in the label. For virtual concatenation, all labels
should be listed in sequence.
S is the index of a particular AUG-1/STS-1. S=1->N indicates a specific AUG-1/STS1 inside an STM-N/STS-N multiplex.
L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for
an unstructured VC-4 or STS-1 SPE. In our application, STS-1 SPE is unstructured.
M indicates a specific branch of a TUG-2/VT Group. It is not significant for an
unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.
Typical example: S>0, U=0, K=0, L=0, M=0
Denotes the unstructured SPE of the Sth STS-1.
4.3.9 Label Request Message ID TLV [8]
This TLV is carried in the Label Mapping Message and it is set to be the Message ID
of the corresponding Label Request Message.
4.3.10 Interface ID TLV [4][5]
GMPLS accommodates both one-to-one association of a control channel to a data
channel and no such association. When several data channels are controlled by the same
control channel, additional information is needed to indicate the particular data channel
being selected for the requested LSP. The IF_ID (Interface ID) TLV is used for this
purpose [4]. When there is one-to-one association of control channels to data channel, it
is recommended to avoid the usage of the IF_ID TLV [5].
The format of the Interface ID TLV is as follows:
U
F
Type
Length
Value
Length (16 bits): Indicates the length of value field in TLV.
Hardware signaling module behavior: If the value of this field exceeds 12, the whole
message should be passed off to the software signaling process.
Type (14 bits): Indicates type of interface being identified. Defined values are:
Type
Length
Description
1
4
IPv4
2
16
IPv6
3
8
IF_INDEX (Interface Index)
4
8
COMPONENT_IF_DOWNSTREAM (Component interface)
5
8
COMPONENT_IF_UPSTREAM (Component interface)
23
The value field for a type 1 or type 2 IF_ID TLV is IPv4 address or IPv6 address
respectively. The value field for a type 3, 4, or 5 IF_ID TLV has the following format.
IP address
Interface ID
Type 3 is used when links are unnumbered. An unnumbered link is one that is not
assigned an IP address [12]. Therefore one common IP address, such as a “Router ID,” is
used in the IP address field of the format shown above. The Interface ID is the number
assigned to the link. No a priori mapping between interface identifiers at two LSRs is
needed. Two LSRs could assign identifiers to the data channels between them
independently and exchange the identifiers by configuration, by means of a protocol such
as LMP[13], by means of RSVP/CR-LDP, or by means of IS-IS or OSPF extensions [14].
Type 4 and 5 are used for a bundled component link as defined in [15].
Hardware signaling module behavior: For our architecture and applications, only type
3 will be handled in the hardware signaling module. If the IF_ID TLV carries a valid
interface ID as set by the software signaling process during initialization, then the TLV
will be processed. If there is no match between the values carried in a message and those
set at initialization, the whole message is passed off to the software signaling process.
5. Summary
This document describes a subset of the GMPLS CR-LDP signaling protocol for
implementation in reconfigurable hardware, such as a Field Programmable Gate Array.
All functionality of the protocol not included in this subset will be implemented in a
software signaling process on a general-purpose microprocessor. A preliminary
implementation of a simple signaling protocol [1] showed promise that our approach of
implementing simple frequent operations in hardware and complex infrequent operations
in software is indeed feasible. However, in migrating from our simple signaling protocol
to the GMPLS CR-LDP signaling protocol many issues remain to be understood:

GMPLS CR-LDP is a generalized protocol applicable to a large variety of
networks.

Choices specific to parameters (e.g., values with global or local significance)
in GMPLS are not favorable for hardware implementation.

The Tag-Length-Value (TLV) structure is used in GMPLS for parameters
instead of fixed location fields.
The GMPLS CR-LDP has evolved from LDP to CR-LDP to CR-LDP with extensions
for GMPLS networks, such as SONET/SDH and DWDM. This complex protocol is now
targeting almost all connection-oriented networks both packet-switched and circuitswitched. This drive impacts almost all fields in parameters within messages. For
example, the address field identifying the destination address of the connection allows for
different address families, IP, telephony E.164, ATM End System Addresses, etc. This
impacts the run-time performance since every field received in all messages should be
24
checked for validity of its value. Furthermore, the size of the executable code for the
signaling protocol becomes very large posing problems in many specialized processors,
such as Network Processors (NPs) that only have 8MB instruction caches.
Next, with regards to choices made for specific parameters, consider a parameter such
as a connection identifier or connection reference. Most signaling protocols have this
parameter. If this is chosen to be globally unique, then connection related data tables need
to be searched with a much larger key than if this is chosen to be locally significant. In
CR-LDP, the connection reference parameter, the LSPID, is a globally significant
parameter. This makes state tables maintained for connections harder to search.
Next, the TLV structure was designed for flexibility, allowing protocol designers to
add parameters in arbitrary order. But this construct makes parameter extraction in
hardware a complex task. The hardware signaling module needs to first read every length
field and then the value, making message parsing a more difficult task. Current NPs
easily handle fixed-field protocols such as IP, Ethernet, ATM, etc., but none of the
current NPs support TLV handling.
In addition to the above list specific to GMPLS CR-LDP, there are issues applicable to
any signaling protocol:

There is a need to initiate messages from a switch instead of always simply
forwarding messages; e.g., a connection release message aborting a
connection setup is needed when resources are not available and no
connection can be preempted, or to release a preempted connection.

There is a need to maintain state information for connections.

The signaling protocol typically uses timers for many actions, such as
releasing resources for aborted connection setups or for connections passing
through a failed node at other switches on the end-to-end paths.

The need to support a variety of procedures, such as third-party connection
control and multiparty connection control.
Despite of all these difficult issues, we believe that hardware implementation of
signaling protocols is well worth attempting. If successful, it will enable many lowlatency interaction-intensive applications for connection oriented networks. At the end of
this study, we hope to either prove that GMPLS CR-LDP can be implemented in this
hardware-software combination architecture, or to prove the need for a simple signaling
protocol targeted at an individual connection-oriented network.
References
[1] H. Wang, M. Veeraraghavan and R. Karri, “A hardware implementation of a signaling protocol,” in
Proc. of Opticomm 2002, July 29-Aug. 2, 2002, Boston, MA..
[2] E. Mannie (editor), “GMPLS Architecture,” IETF Internet Draft, draft-ietf-ccamp-gmpls-architecture02.txt, March 2002.
[3] E. Mannie (editor) et al., “GMPLS Extensions for SONET and SDH Control, IETF Internet Draft,
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt, October 2001.
25
[4] P. Ashwood-Smith, et al., “Generalized MPLS - Signaling Functional Description,” IETF Internet
Draft, draft-ietf-mpls-generalized-signaling-05.txt, July 2001.
[5] P. Ashwood-Smith, et al., “Generalized MPLS Signaling - CR-LDP Extensions,” IETF Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-03.txt, May 2001.
[6] P. Ashwood-Smith, et al., “Generalized MPLS - RSVP-TE Extensions,” IETF Internet Draft, draftietf-mpls-generalized-rsvp-te-04.txt, July 2001.
[7] B. Jamoussi (editor), et al., “Constraint-Based LSP Setup using LDP,” IETF RFC 3212, Jan. 2002.
[8] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, “LDP Specification,” IETF RFC 3036,
Jan. 2001.
[9] Eric Mannie (editor), et al., “Generalized Multiprotocol Label Switching Extensions to Control
Non-Standard SONET and SDH Features,” IETF Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdhextensions-00.txt, October 2001.
[10] D. Papadimitriou (editor), et al., “GMPLS Signalling Extensions for G.709 Optical Transport
Networks Control,” IETF Internet Draft, draft-ietf-ccamp-gmpls-g709-00.txt, March 2002.
[11] P. De Dobbelaere, K. Falta, S. Gloeckner, S. Patra, “Digital MEMS for optical switching,” IEEE
Communications Magazine, Volume 40, Issue 3, March 2002.
[12] Kireeti Kompella, Yakov Rekhter, Alan Kullberg, “Signalling Unnumbered Links in CR-LDP,” IETF
Internet Draft, draft-ietf-mpls-crldp-unnum-05.txt, March 2002.
[13] Jonathan P. Lang, Krishna Mitra, John Drake, Kireeti Kompella, Yakov Rekhter, Lou Berger,
Debanjan Saha, Debashis Basak, Hal Sandick, Alex Zinin, Bala Rajagopalan, “Link Management
Protocol,” IETF Internet Draft, draft-ietf-ccamp-lmp-02.txt, November 2001.
[14] K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie
D. Saha, V. Sharma, “OSPF Extensions in Support of Generalized MPLS,” IETF Internet Draft, draftietf-ccamp-ospf-gmpls-extensions-03.txt, May 2002.
[15] Kireeti Kompella, Yakov Rekhter, Lou Berger, “Link Bundling in MPLS Traffic Engineering,” IETF
Internet Draft, draft-ietf-mpls-bundle-01.txt, November 2001.
[16] G. Bernstein, E. Mannie, V. Sharma, “Framework for GMPLS-based Control of SDH/SONET
Networks,” IETF Internet Draft, draft-ietf-ccamp-sdhsonet-control-00.txt, Feb. 2002.
26