Hardware-Accelerated Signaling: Design,
Implementation and Implications
DISSERTATION
(APPENDIX)
for the Degree of
DOCTOR OF PHILOSOPHY
(Electrical Engineering)
HAOBO WANG
November 2004
i
Abbreviations and AcronymsAIS Alarm Indication Signal
ASIC Application Specific Integrated Circuit
ATM Asynchronous Transfer Mode
BLSR Bidirectional Line Switched Ring
CAC Connection Admission Control
CR-LDP Constraint-based Routing-LDP
DWDM Dense WDM
FEC Forward Equivalent Class
FPGA Field Programmable Gate Orrery
FSC Fiber-Switch Capable
GbE Gigabit Ethernet
GMPLS Generalized MPLS
IETF Internet Engineering Task Force
IS-IS Intermediate System-to-Intermediate System
LDP Label Distribution Protocol
LMP Link Management Protocol
LSC Lambda Switch Capable
LSP Label Switched Path
LSR Label Switched Router
MEMS MicroElectro-Mechanical Systems
MPLS MultiProtocol Able Switching
OC Optical Carrier
OCSP Optical Circuit Signaling Protocol
OSPF Open Shortest Path First
OSPF-TE OSPF - Traffic Engineering
PDU Protocol Data Unit
QoS Quality of Service
RSVP Resource reSerVation Protocol
RSVP-TE RSVP-Traffic Engineering
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical NETwork
STS Synchronous Transport Signal
TDM Time Division Multiplexing
ULSR Unidirectional Line Switched Ring
ii
URL Uniform Resource Locator
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
VPC Virtual Path Connection
VPI Virtual Path Identifier
WDM Wavelength Division Multiplexing
iii
ContentsAbbreviations and Acronyms.......................................................................................... i
Appendix A: Specification of a Subset of RSVP-TE for Hardware Implementation 1
A.1 Introduction ........................................................................................................ 1A.2 Background......................................................................................................... 3A.3 Our architecture and applications ....................................................................... 7
A.3.1 Architecture ............................................................................................. 7A.3.2 Applications ............................................................................................. 9A.3.3 Functionality defined in this subset ....................................................... 12
A.4 Subset specification for the hardware signaling accelerator............................. 15A.4.1 RSVP messages ..................................................................................... 16
A.4.1.1 Common header........................................................................ 17A.4.1.2 Path Message ............................................................................ 18A.4.1.3 Resv Message ........................................................................... 19A.4.1.4 PathTear Message..................................................................... 20A.4.1.5 ResvTear Message .................................................................... 21
A.4.2 RSVP Objects ........................................................................................ 21A.4.2.1 FILTER_SPEC ......................................................................... 22A.4.2.2 FLOWSPEC ............................................................................. 23A.4.2.3 LABEL (Generalized) .............................................................. 23A.4.2.4 LABEL_REQUEST (Generalized) .......................................... 26A.4.2.5 RSVP_HOP .............................................................................. 28A.4.2.6 SENDER_TEMPLATE............................................................ 31A.4.2.7 SENDER_TSPEC..................................................................... 32A.4.2.8 SESSION .................................................................................. 35A.4.2.9 STYLE...................................................................................... 37A.4.2.10TIME_VALUES ...................................................................... 38
A.5 Summary........................................................................................................... 39
Appendix B: Detailed Description of RSVP-TE Signaling Procedures 42
B.1 Introduction ...................................................................................................... 42B.2 Registers ........................................................................................................... 44B.3 Data tables ........................................................................................................ 45
B.3.1 Routing table.......................................................................................... 46B.3.2 Incoming Connectivity table.................................................................. 47B.3.3 Incoming CAC table .............................................................................. 48B.3.4 Outgoing Connectivity table .................................................................. 49B.3.5 Outgoing CAC table .............................................................................. 50B.3.6 User/Control Mapping table .................................................................. 50B.3.7 State table............................................................................................... 51
iv
B.4 Procedures......................................................................................................... 54
Appendix C: 76
C.1 Comparison of RSVP-TE and OCSP ............................................................... 76C.2 Explanation for connection reference............................................................... 77C.3 Explanation for Style ........................................................................................ 80
v
List of FiguresFigure 1. Ordered control................................................................................................. 4Figure 2. Unfolded view of a switch................................................................................ 9Figure 3. Network architecture. ....................................................................................... 9Figure 4. Ring restoration application. .......................................................................... 10Figure 5. File transfers between the Server and Client. ................................................. 11Figure 6. SONET multiplexing hierarchy and generalized label................................... 26Figure 7. Prefixes and suffixes used in this document................................................... 43Figure 8. Network used for illustrative examples.......................................................... 46Figure 9. Signaling message flow for setting up a unidirectional circuit ...................... 46Figure 10. Example of Avail_BW. .................................................................................. 48Figure 11. State transition diagram.................................................................................. 53Figure 12. Processing of common header........................................................................ 57Figure 13. Processing of Path message............................................................................ 57Figure 14. SESSION and SENDER_TEMPLATE objects in Path message................... 58Figure 15. Processing of RSVP_HOP object in Path message........................................ 59Figure 16. Processing of TIME_VALUES object in any message.................................. 60Figure 17. Processing of SENDER_TSPEC object in Path message. ............................. 60Figure 18. Processing of LABEL_REQUEST object in Path message. .......................... 61Figure 19. At the end of Path message processing. ......................................................... 62Figure 20. Assemble new Path message. ......................................................................... 63Figure 21. Processing of Resv message........................................................................... 64Figure 22. Processing of SESSION and FILTER_SPEC objects in Resv message. ....... 65Figure 23. Processing of RSVP_HOP in Resv message.................................................. 66Figure 24. Processing of STYLE object in any message................................................. 67Figure 25. Processing of FLOWSPEC object in Resv message. ..................................... 67Figure 26. Processing of LABEL object in Resv message. ............................................. 68Figure 27. At the end of Resv message processing. ........................................................ 69Figure 28. Assemble new Resv message. ........................................................................ 69Figure 29. Processing of PathTear message. ................................................................... 70Figure 30. Processing of SESSION and SENDER_TEMPLATE objects in PathTear mes-
sage. ................................................................................................................ 71Figure 31. At the end of PathTear message processing. .................................................. 72Figure 32. Assemble new PathTear message................................................................... 72Figure 33. Processing of ResvTear message.................................................................... 73Figure 34. Processing of SESSION and FILTER_SPEC objects in ResvTear message. 74Figure 35. At the end of ResvTear message processing. ................................................. 75Figure 36. Assemble new ResvTear message.................................................................. 75Figure 37. LSP tunnels, LSPs, TE tunnels....................................................................... 79
vi
List of TablesTable 1. Registers extracted from messages............................................................ 44Table 2. Initialization registers ................................................................................ 45Table 3. Routing table ............................................................................................. 46Table 4. Incoming Connectivity table ..................................................................... 47Table 5. Incoming Connectivity table at switch II in Fig. 8.................................... 48Table 6. Incoming CAC table.................................................................................. 48Table 7. Incoming CAC table at switch II in Fig. 8 ................................................ 48Table 8. Outgoing Connectivity table...................................................................... 49Table 9. Outgoing Connectivity table for switch I in Fig. 8.................................... 50Table 10. Outgoing CAC table .................................................................................. 50Table 11. Outgoing CAC table for switch I in Fig. 8 ................................................ 50Table 12. User/Control Mapping table ...................................................................... 50Table 13. State table .................................................................................................. 51Table 14. An example state table entry at switch II for the connection shown in
Fig. 8.......................................................................................................... 53Table 15. Updating State table after processing a Path message............................... 62Table 16. Mapping parameters of OCSP to RSVP fields in objects ......................... 76
1
Appendix A: Specification of a Subset of RSVP-TE for
Hardware Implementation1
A.1 Introduction
Signaling protocols in switches are primarily implemented in software for two rea-
sons. 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.
Even with state-of-the-art processors, software implementations of signaling protocols are
rarely capable of handling over 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) net-
works, which we call Optical Circuit Signaling Protocol (OCSP). To address the flexibility
issue, we implemented OCSP in reconfigurable hardware, i.e., Field Programmable Gate
Arrays (FPGAs). These devices are a compromise between general-purpose processors at
one end of the flexibility-performance spectrum, and Application Specific Integrated Cir-
cuits (ASICs) at the opposite end of this spectrum. FPGAs can be re-programmed with
1 This work is sponsored by a NSF grant, 0087487, and by NYSTAR (The New York Agency of Science, Technologyand Academic Research) through the Center for Advanced Technology in Telecommunications (CATT) at PolytechnicUniversity.
1000
2
updates as signaling protocols evolve while significantly improving call handling capaci-
ties relative to software implementations. To handle the complexity issue, we define a sub-
set of the signaling protocol specific to the target architecture and applications for
hardware acceleration. This subset should include all time-critical operations. Non-time-
critical operations (for example, processing of optional parameters, error handling, etc.)
are relegated to software.
When we defined our signaling protocol for SONET networks in 1999, the General-
ized MultiProtocol Label Switching (GMPLS) effort in the IETF was just getting under-
way. Now the GMPLS working group has generated many specifications [2]-[6]. Among
these specifications are adaptations of Resource ReSerVation Protocol - Traffic Engineer-
ing (RSVP-TE) [7], which is itself a traffic engineering extension of the Resource reSer-
Vation Protocol (RSVP) [8], and Constraint Routing based Label Distribution Protocol
(CR-LDP). 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., RSVP-TE for GMPLS with
SONET/SDH extensions.
Of the two GMPLS signaling protocols specified, RSVP-TE and CR-LDP, we choose
RSVP-TE because it is more popular in the industry. Both RSVP-TE and CR-LDP are
similar and either can be selected to demonstrate the feasibility and advantages of hard-
ware acceleration.
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 imple-
menting only a subset of the protocol in hardware and the remaining portion in software
3
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 sub-
set of RSVP-TE for our hardware implementation. Besides, as a protocol originally
designed for packet-switched networks, many of its parameter fields are not applicable for
circuit-switched SONET/SDH/WDM networks.
Section 2 provides background on GMPLS signaling. Section 3 describes our target
architecture and applications, for which we specify a subset of RSVP-TE for hardware
implementation. This subset specification is described in Section 4. Section 5 summarizes
Appendix A.
A.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-TE and CR-LDP signaling. The GMPLS sig-
naling specification consists of a signaling functional description [3], RSVP-TE exten-
sions [4] and CR-LDP extensions [5]. In addition, there are technology-specific
extensions such as GMPLS extensions for SONET and Synchronous Digital Hierarchy
(SDH) control [6][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
4
• 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 connections1 are unidirectional, a switch SW1 is an “upstream” neigh-
bor 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 downstream-
unsolicited label allocation mode where a switch can initiate the allocation and distribu-
tion of a label without being explicitly asked to do so. In GMPLS, only the former proce-
dure 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 Path messages flowing
from upstream switches toward their downstream neighbors, and Resv messages flowing
in the reverse direction as shown in Fig. 1. This mode of control is in contrast to indepen-
1 We use the generic term “connections” interchangeably with the term “Label Switched Paths (LSPs).”
Figure 1. Ordered control.
SwitchSW4
SwitchSW5
SwitchSW1 Switch
SW2
SwitchSW3
Source Destination
1. Path2. Path 3. Path
4. Path
5. Tear6. Tear7. Tear8. Tear
9. Connection (circuit orvirtual circuit) established
5
dent control where switch SW2 can allocate a label in response to a Path message from an
upstream switch even if the connection is not established downstream of switch SW2.
GMPLS requires the use of 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 next-
hop 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. In
RSVP, given the support for soft-state and periodic Refresh messages, a Refresh arriving at
a transit switch could cause the release of a connection if the routing data has changed, and
if the label retention mode is conservative. Furthermore, if a Refresh does not arrive before
the refresh interval times out, then a switch will release the LSP.
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 net-
work at the IP layer and initiates the set up of a connection. Topology changes in the con-
nection-oriented network, such as link failures, could trigger a re-establishment of
6
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 con-
trast, 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 sup-
porting 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
6. Bi-directional Label Switched Path (LSP) establishment
7. Rapid failure notification extensions
8. Protection information currently focusing on link protection, plus primary and second-
ary 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 packet-
and circuit-switched, and hence has many options. Only building blocks 1, 2 and 10 are
7
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].
A.3 Our architecture and applications
As described in Section 2, there are many versions of RSVP: traditional RSVP, RSVP-
TE, RSVP-TE for GMPLS networks, RSVP-TE for GMPLS 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 param-
eters 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 hard-
ware implementation based on a specific target architecture and applications. In this sec-
tion, we define our target architecture and applications.
A.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
8
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, signal-
ing 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 mes-
sages only carry a peak (or constant) rate traffic descriptor. Second, among the various cir-
cuit switches available, we eliminated optical WDM 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 Gigabit 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 mes-
sages. Therefore, we plan on using GbE links for the signaling links. This means a com-
mon control channel carries signaling messages for all interfaces between two switches.
Fig. 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 accelerator, which will be implemented in reconfigurable hardware
such as FPGA, and a Software signaling process, which is a process running on a general-
purpose microprocessor. Other software processes such as the illustrated Routing process
will be needed. Maintenance and management software is omitted for clarity from Fig. 2.
9
The input and output signaling interfaces are GbE links.
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 Fig. 3.
A.3.2 Applications
We target this specification of the RSVP-TE subset for two applications. The first
Figure 2. Unfolded view of a switch.
SignalingHardware
Accelerator
SwitchFabric
uPRoutingprocess
Signalingprocess
Control plane
User plane
NIC
NIC
NIC
NIC
Linecard
Linecard
Linecard
Linecard
Input signalingInterface
Output signalingInterface
InputInterface Output
Interface
SW1 SW5
SW2 SW6
SW3 SW4
EndDevice 1 End
Device 2
Physical Link
Traffic Engineering Link ("fat pipe")SW#
SONETSwitch
The LSP between End Device 1 and End Device 2
Figure 3. Network architecture.
10
application is restoration in a SONET ring. When a failure occurs, the ends of paths tra-
versing the failed link detect the failure through signals such as path-AIS (Alarm Indica-
tion Signal) and initiate restoration procedures. All restoration is on unidirectional
circuits. For example, if the ring is a Unidirectional Line Switched Ring (ULSR), then typ-
ically only one direction of the circuits need to be restored after the first failure (in the
example shown in Fig. 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 RSVP-
TE subset, the circuit in each direction is restored with a separate set of signaling mes-
sages.
Fig. 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 restora-
tion 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 Path mes-
sage. This allows for it to start sending data when it receives the Resv message after the
Figure 4. Ring restoration application.
R4 ADM4 ADM2
AD
M3
AD
M1
R2
R1
R3
11
ordered downstream-on-demand setup.
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 Fig. 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 Path
message to a downstream node leading to the client. Again the downstream node should
send another Path message to the next hop in its routing table. Path messages are sent
switch-to-switch from the server to the client in such a way. The client responds with a
Resv message to the node from which the client receives the Path message. Resv messages
are sent switch-to-switch from the client to the server. The server starts data flow once it
receives the Resv message. Thus the sending end of the unidirectional circuit is the initia-
tor of the Path message.
LEGEND
IP Router
CO Switch
Client
Server
TCP/IP path
SONET circuit
Figure 5. File transfers between the Server and Client.
12
For releasing a connection, the client initiates the release after it has received the
whole file. It sends a ResvTear message; this works well with the RSVP-TE specification
in which the downstream Label Switched Router (LSR) is the one that initiates label Resv-
Tear.
A.3.3 Functionality defined in this subset
To support the above-described architecture and applications, we identify a subset of
signaling functions that will be handled by a hardware signaling accelerator. Remaining
functions will be handled by a software signaling process.
Functions to be implemented in the hardware signaling accelerator are as follows.
• The set up and release of point-to-point unidirectional LSPs at a transit SONET
switch. We do not implement signaling functions at an ingress or egress node of an
LSP.
• We allow for the presence of logical links (LSP pipes) on end-to-end paths. This
means switches that are not physically connected by direct links could be neighbors.
• We allow for the bandwidth of the circuit being set up to be negotiated. RSVP allows
for the Resv message sent to an upstream switch to carry a different set of values in the
traffic parameter than in the Resv message received from the downstream switch. This
is allowed for merging flows in a multipoint connection. In our file transfer applica-
tion, given that “any” bandwidth can be used for the file transfer, we allow any switch
or the receiving client to change the bandwidth of the connection being setup.
• The newly defined virtual concatenation scheme for SONET networks allows for dif-
ferent components of the virtually concatenated signal to be routed on different paths.
For example, when setting up a virtually concatenated signal of 7 VT1.5s to carry a
13
10Mb/s Ethernet signal, a situation may arise where a switch does not have sufficient
bandwidth to route 7VT1.5s on the same interface to the next-hop node. Ideally, the
switch should then trigger multiple Path messages to set up different components of
the signal via different interfaces to the same next-hop node or to different next-hop
nodes. However, this is a complex operation requiring multiple Path messages to be
created in response to one. Hence we relegate this operation to the software signaling
process, and only support connection routing on one interface in the hardware signal-
ing accelerator.
• RSVP supports the notion of soft state and periodic refresh messages. If a refresh is
not received before the timeout interval expires, connections should be released. These
concepts were defined primarily because topology information about a multicast tree
is likely to change and hence corresponding state information should be changed. A
second reason described in [8] for refresh messages is that since RSVP uses unreliable
IP service, the occasional loss of an RSVP message is handled through refreshes. RFC
2961 [12] discusses that the choice of the refresh interval is influenced in opposite
directions by two factors. If the refresh interval is small, then the overhead spent in
processing refresh messages can become excessive. If the refresh interval is large, then
it takes longer to detect the loss of an RSVP message. This can be significant. If, for
example, the lost message is a first Path message, call setup delay can become signifi-
cant. To avoid such a delay, RFC 2961 introduce new parameters called
MESSAGE_ID and MESSAGE_ID_ACK, along with the concept of retransmission
timers and exponential backoffs of retransmission timer values for failed retries. These
provide for reliable transport of RSVP messages. Using these extensions to ensure
14
reliable transport, the purpose of refresh messages becomes limited to just ensuring
that state information changes as topology/routing information changes. It then
becomes possible to increase refresh timers and decrease overhead. Furthermore, in
GMPLS, the need for refreshes becomes even less. Once a SONET/SDH/WDM cir-
cuit is set up, even if routing data changes, the connection can be held on the old path,
especially if connection holding times are small as in our file transfer application.
Nevertheless, since refresh time-out values are mandatory in RSVP messages, we
implement our hardware signaling accelerator to store these values, but processing of
refresh messages and checking for time-outs will be relegated to the software signal-
ing process. We expect refresh messages in GMPLS networks to be few. If refreshes
are not used to detect loss of RSVP messages in GMPLS networks, then some scheme
such as the extensions proposed in RFC 2961, should be implemented. This suggests
that even though these extensions are currently optional in GMPLS [4], they may
become widely adopted in implementations of RSVP-TE for GMPLS networks. For
this version of our hardware signaling accelerator, we do not process messages carry-
ing these optional fields due to difficulties in implementing timers in hardware. How-
ever, this is the most important set of optional parameters to implement in a
subsequent hardware signaling accelerator because of its implication on reliable trans-
port. It is not feasible to mandate service providers to route signaling links between
neighboring switches on direct physical links or highly-reliable logical links. Since
these links are likely to be Ethernet, it is quite possible for a signaling link between
two switches to be routed through connectionless packet switches (Ethernet switches
15
or IP routers). Packet losses in such switches will result in lost RSVP messages. Build-
ing in reliable transport is important for signaling messages.
• The hardware signaling accelerator supports only the Fixed-Filter (FF) reservation
style with one flow descriptor. For our applications, we assume all connections are
point-to-point. For point-to-point connections, only the FF style is applicable. Further-
more, we limit the number of flow descriptors handled by the hardware signaling
accelerator to 1. If there are multiple flow descriptors in the list, the message is passed
to the software signaling process because it may require a switch to generate multiple
Resv messages one toward each sender.
• The hardware signaling accelerator supports the concept of separation of control plane
and user plane interfaces.
A.4 Subset specification for the hardware signaling accelerator
From RSVP to RSVP-TE, to RSVP-TE with extensions for GMPLS, to the extensions
for SONET/SDH, some messages/objects/procedures are obsolete, some are newly intro-
duced, some are not applicable to new applications, some once optional are now manda-
tory. Among all the messages, objects, and procedures applicable to our target application,
RSVP-TE for GMPLS with SONET/SDH extensions, some are complex, and non-time-
critical, we relegate these functions to software. In this section, we identify a subset of
RSVP-TE for GMPLS with SONET/SDH extensions, which will be implemented in
reconfigurable hardware.
All exceptions or errors, such as missing of mandatory objects, presence of optional
objects, should also be relegated to the software signaling process.
16
A.4.1 RSVP messages
There are 7 messages defined in traditional RSVP, Path, Resv, PathErr, ResvErr, Path-
Tear, ResvTear, and ResvConf. RSVP-TE added Hello message for the purpose of node
failure detection. When RSVP-TE was enhanced for GMPLS, Notify message was intro-
duced to support fast failure notification.
Among these messages, Path and Resv messages are used to set up an LSP, PathTear/
ResvTear is used to tear down an LSP. These four messages should be processed by hard-
ware. ResvConf message, used to confirm Resv message, is triggered by an optional
object, RESV_CONFIRM, in Resv message. We assume normally there is no ResvConf
message in our application. All other messages, PathErr, ResvErr, Hello, and Notify, are
non-time-critical. These four messages, together with ResvConf, should be processed by
software.
All RSVP messages begin with a common header, followed by a body consisting of a
variable number of variable-length, typed “objects”. The following subsections detail the
format of the common header, and the four RSVP messages to be processed by hardware.
Messages are defined in Backus-Naur Form (BNF)1. We omit all optional objects in the
messages. The order of the objects in a message is recommended, but not mandatory,
which means an implementation should create messages with the objects in the order
shown below, but accept the objects in any permissible order.
1 Backus-Naur Form (BNF), introduced by John Backus and improved by Peter Naur, is one of the most commonly usedmeta-syntactic notation for specifying the syntax of programming languages, command sets, and the like. The meta-symbols of BNF are:::= meaning “is defined as” | meaning “or”<> angle brackets used to surround item names[] square brackets used to surround optional itemsThe BNF implies an order for the items.
17
A.4.1.1 Common header
Common header is defined in [8], page 32.
• Vers: 4 bits
Protocol version number. This is version 1.
Hardware signaling accelerator behavior: Check the value of this field, and pass the
message to the software signaling process if the value is other than 1.
• Flags: 4 bits
No flag bits are defined yet.
• Msg Type: 8 bits
Hardware signaling accelerator behavior: Save this field in a register, check its value,
and pass the message to the software signaling process if the value is other than 1, 2, 5
or 6.
• RSVP Checksum: 16 bits
The one’s complement of the one’s complement sum of the message.
Vers Flags Msg Type RSVP Checksum Send_TTL (Reserved) RSVP Length
Value Type1 Path2 Resv3 PathErr4 ResvErr5 PathTear6 ResvTear7 ResvConf
20 Hello21 Notify
18
Hardware signaling accelerator behavior: Save this field in a register, and calculate
local checksum. Pass the message to the software signaling process if the checksum
indicates an error.
• Send_TTL: 8 bits
The IP TTL value with which the message was sent, used to detect a non-RSVP hop.
Hardware signaling accelerator behavior: Decrease this field by one, save it in register.
• RSVP Length: 16 bits
The total length of this RSVP message in bytes.
Hardware signaling accelerator behavior: Save this field in a register, and use it to
delimit the message.
A.4.1.2 Path Message
Path message was initially defined in [8], page 36. There are three mandatory objects,
SESSION, RSVP_HOP, and TIME_VALUES. Path message was modified in [7] to sup-
port MPLS, page 15. A new mandatory object, LABEL_REQUEST, was introduced.
Sender descriptor, including SENDER_TEMPLATE and SENDER_TSPEC objects,
became mandatory. Reference [4] enhanced Path message to support GMPLS, page 31.
Path Message>::= <Common Header>
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
<LABEL_REQUEST>
<sender descriptor>
<sender descriptor>::= <SENDER_TEMPLATE>
19
<SENDER_TSPEC>
A Path message is used by an upstream LSR to ask a downstream LSR to allocate a
label for an LSP. More generally, it is a request to set up an LSP. There are 6 objects man-
datory in Path Message, SESSION, RSVP_HOP, TIME_VALUES, LABEL_REQUEST,
SENDER_TEMPLATE, and SENDER_TSPEC. The details of these objects will be given
in Section 4.2.
Hardware signaling accelerator behavior: Pass the message to the software signaling
process if any objects other than the ones listed above are present.
A.4.1.3 Resv Message
Resv message was initially defined in [8], page 38. The mandatory objects include
SESSION, RSVP_HOP, TIME_VALUES, and a list of flow descriptors; each, in turn,
includes two mandatory objects, FLOWSPEC and FILTER_SPEC, which should appear
in order. Resv message was modified in [7] to support MPLS, page 16. A new mandatory
object, LABEL, was introduced for each flow descriptor. Reference [4] enhanced Resv
message to support GMPLS, page 32. But no more mandatory object was introduced.
<Resv Message>::= <Common Header>
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
<STYLE>
<flow descriptor list>
<flow descriptor list>::=<FLOWSPEC>
<FILTER_SPEC>
20
<LABEL>
A Resv message is used by a downstream LSR to advertise the binding of a label to a
specific LSP. After a label is allocated for an LSP, a Resv message, which carries the label
assigned to the LSP, is sent to the upstream LSR. There are 7 objects mandatory in Resv
message, SESSION, RSVP_HOP, TIME_VALUES, STYLE, FLOWSPEC,
FILTER_SPEC, and LABEL. The details of these objects will be given in Section 4.2.
Hardware signaling accelerator behavior: Pass the message to the software signaling
process if any objects other than the ones listed above are present. We also limit the flow
descriptor list to consist of only one descriptor, which consists of a FLOWSPEC, a
FILTER_SPEC and a LABEL. In general, the flow descriptor list can have multiple flow
descriptors. Our reason for this limitation is described in Section 3.3.
A.4.1.4 PathTear Message
PathTear message was initially defined in [8], page 41. No further modifications have
been made in RSVP-TE.
<PathTear Message>::= <Common Header>
<SESSION>
<RSVP_HOP>
<sender descriptor>
<sender descriptor>::= <SENDER_TEMPLATE>
In RSVP-TE (GMPLS), either source or destination can tear down an LSP. Source
node tears down an LSP by sending out PathTear message, while the destination node
does so by sending an ResvTear message. The details of these objects will be given in Sec-
tion 4.2.
21
Hardware signaling accelerator behavior: Pass the message to the software signaling
process if any object other than the ones listed above are present.
A.4.1.5 ResvTear Message
ResvTear message was initially defined in [8], page 42. No further modifications have
been made in RSVP-TE.
<ResvTear Message> :: =<Common Header>
<SESSION>
<RSVP_HOP>
<STYLE>
<flow descriptor list>
<flow descriptor list>::=<FLOWSPEC>
<FILTER_SPEC>
The details of these objects will be given in Section 4.2.
Hardware signaling accelerator behavior: Pass the message to the software signaling
process if there is more than one flow descriptor in the flow descriptor list, or if any object
other than the ones listed above are present.
A.4.2 RSVP Objects
Object, a <type, length, value> triplet, is an element of an RSVP control message. It
consists of one or more 32-bit words with a one-word header.
• Length: 16 bits
The total object length in bytes.
Length (bytes) Class-Num C-Type(Object contents)
...
22
Hardware signaling accelerator behavior: Use this field to delimit the object.
• Class-Num: 8 bits
Identifies the object class.
Hardware signaling accelerator behavior: Check this field, and pass the message to the
software signaling process if the specified object is not part of this subset definition.
See Sections 4.1.2-4.1.5 for the types of objects to be handled by the hardware signal-
ing accelerator for the 4 messages, and Sections 4.2.1-4.2.10 for specific Class_Num
values handled by the hardware signaling accelerator.
• C-Type: 8 bits
Object type, unique within Class-Num.
Hardware signaling accelerator behavior: Check this field, and pass the message to the
software signaling process if the specified C-Type is not part of this subset as defined
in Sections 4.2.1-4.2.10 for the corresponding Class_Num.
A.4.2.1 FILTER_SPEC
FILTER_SPEC object was initially defined in [8], Class-Num 10, C-Type 1-3. In [7],
C-Types 7-8 were added in support of LSP tunnel. In our application, C-Type is 7, mean-
ing IPv4 LSP tunnel.
Hardware signaling accelerator accepts this object Class-Num=10 if C-Type=7. Other-
wise, it passes the message to the software signaling process.
The format of the FILTER_SPEC object is identical to the SENDER_TEMPLATE
object. FILTER_SPEC object is carried in Resv message while SENDER_TEMPLATE
object is carried in Path message. Please refer to SENDER_TEMPLATE object for
details.
23
A.4.2.2 FLOWSPEC
FLOWSPEC object was initially defined in [8], Class-Num 9, C-Type 1-2. In [6], a
new C-Type was introduced to support SONET/SDH traffic parameters. The value for this
C-Type is not determined yet.
Hardware signaling accelerator accepts this object Class-Num=9 if C-Type=TBA.
Otherwise, it passes the message to the software signaling process.
The format of the FLOWSPEC object is identical to the SENDER_TSPEC object.
FLOWSPEC object is carried in Resv message while SENDER_TSPEC object is carried
in Path message. Please refer to SENDER_TSPEC object for details.
A.4.2.3 LABEL (Generalized)
LABEL object was initially defined in [7] to support the setup of an LSP tunnel, Class-
Num 16, C-Type 1. In [3][4], LABEL is generalized to represent timeslot, wavelength,
switch port, etc. Two more C-Types 2-3 were suggested. Reference [6] defined the gener-
alized LABEL for SONET/SDH.
Hardware signaling accelerator accepts this object Class-Num=16 if C-Type=2. Other-
wise, it passes the message to the software signaling process.
The Generalized Label object, carried in Resv message, extends the traditional label by
allowing the representation of not only labels which travel in-band with associated data
packets, but also labels which identify timeslots, wavelengths, or space division multi-
plexed position. In our application, SONET, a label represents a set of timeslots.
Each Generalized Label object carries a variable length label. The format of the label
Length Class-Num(16) C-Type(2)Label
...
24
depends on the application. The format of a SONET/SHD label is shown as follows.
• S: 16 bits (1->N)
Indicates a particular STS-3/AUG-1 inside an STS-N/STM-N multiplex, S is only sig-
nificant for SONET STS-N (N>1)/SDH STM-N (N>0), and must be 0 and ignored for
STS-1/STM-0.
• U: 4-bit (1->3)
The index of a particular STS-1 SPE/VC-3 within an STS-3/AUG-1, U is only signifi-
cant for SONET STS-N (N>1)/SDH STM-N (N>0), and must be 0 and ignored for
STS-1/STM-0.
• K: 4-bit (1->3)
The index of a particular TUG-3 within a VC-4, only significant for an SDH VC-4
structured in TUG-3s, and must be 0 and ignored in all other cases.
• L: 4 bits (1->7)
S U K L M
S SONET
0 OTHER
1 1st STS-3
2 2nd STS-3
3 3rd STS-3
4 4th STS-3
... ...
N Nth STS-3
U SONET STS-3
0 OTHER
1 1st STS-1 SPE
2 2nd STS-1 SPE
3 3rd STS-1 SPE
25
Indicates a particular VT Group/TUG-2 within an STS-1 SPE/TUG-3 or VC-3, must
be 0 and ignored in all other cases.
• M: 4 bits
Indicates a particular VT1.5 SPE/VC-11, VT2 SPE/VC-12 or VT3 SPE within a VT
Group/TUG-2, must be 0 and ignored in all other cases.
Fig. 6 shows the association of a Generalized Label to the SONET multiplexing hier-
archy. The granularity can be as fine as 1.544Mbps (DS1).
Hardware signaling accelerator behavior: The switch fabric we plan to use is Vitesse
VSC9182, which has 64 input/output ports, each port supports STS-12, the granularity
is STS-1. K field is used for SDH only and hence not checked by this hardware signal-
L SONET STS-1 SPE
0 OTHER
1 1st VTG
2 2nd VTG
3 3rd VTG
4 4th VTG
5 5th VTG
6 6th VTG
7 7th VTG
M SONET VTG
0 OTHER
1 1st VT3 SPE
2 2nd VT3 SPE
3 1st VT2 SPE
4 2nd VT2 SPE
5 3rd VT2 SPE
6 1st VT1.5 SPE
7 2nd VT1.5 SPE
8 3rd VT1.5 SPE
9 4th VT1.5 SPE
26
ing accelerator because our target switch is a SONET switch. L and M fields are used
to specify a tributary in low order SONET/SDH hierarchy and hence not checked by
this hardware signaling accelerator because the granularity of our target switch is STS-
1. S and U fields are used to determine a timeslot as shown in Fig. 6. A transit LSR
saves the label in the State table. Besides, LSR programs the switch fabric according to
the received label (for output interface) and the locally allocated label (for input inter-
face) when processing the Label object in a Resv message.
A.4.2.4 LABEL_REQUEST (Generalized)
LABEL_REQUEST object was initially defined in [7] to support the setup of an LSP
tunnel, Class-Num 19, C-Type 1-3. In [3][4], a generalized LABEL_REQUEST object
was introduced, suggested C-Type 4.
Hardware signaling accelerator accepts this object Class-Num=19 if C-Type=4. Other-
wise, it passes the message to the software signaling process.
The Generalized Label Request object defines the characteristics of the requested LSP.
The software signaling process will download the appropriate values for the parameters of
Figure 6. SONET multiplexing hierarchy and generalized label.
STS-3N
STS-3 SPE 3c
STS-1 SPE
VT Group VT-6
VT-3
VT-2
VT-1.5
xN
x3
x7
L
x2
x3
x4
M
44.736MB
44.736MBDS3
6.312MBDS2
2.048MBE1
3.152MBDS1C
1.544MBDS1
For example, S>0, U=1, K=0, L=0, M=0denotes the unstructured SPE of the s-th STS-3and the 1st STS-1.
US
27
this object based on the type of switch served by the signaling engine.
• LSP Encoding Type: 8 bits
Indicates the encoding of the LSP being requested.
Hardware signaling accelerator behavior: Save this field in a register, check its value,
and pass the message to the software signaling process if the value is other than 5.
• Switching Type: 8 bits
Indicates the type of switching performed on a link.
Length Class-Num(19) C-Type(4)[TBA]LSP Enc. Type Switching Type G-PID
Value Type1 Packet2 Ethernet3 ANSI/ETSI PDH4 Reserved5 SDH ITU-T G.707/SONET ANSI
T1.1056 Reserved7 Digital Wrapper8 Lambda (photonic)9 Fiber
10 Reserved11 FiberChannel
Value Type1 Packet-Switched Capable-1 (PSC-1)2 Packet-Switched Capable-1 (PSC-2)3 Packet-Switched Capable-1 (PSC-3)4 Packet-Switched Capable-1 (PSC-4)
51 Layer-2 Switch Capable (L2SC)100 Time-Division-Multiplex Capable (TDM)150 Lambda-Switch Capable (LSC)200 Fiber-Switch Capable (FSC)
28
Hardware signaling accelerator behavior: Save this field in a register, check the value
of this field, and pass the message to the software signaling process if the value is
other than 100.
• Generalized PID (G-PID): 16 bits
An identifier of the payload carried by an LSP, i.e., an identifier of the client layer of
that LSP.
Hardware signaling accelerator behavior: Save this field in a register, do not process it.
This field should be processed by end hosts/ingress and egress routers of an LSP;
hence all transit LSRs (see Section 3.3) pass it transparently.
A.4.2.5 RSVP_HOP
RSVP_HOP object was initially defined in [8], Class-Num 3, C-Type 1-2. In [4], in
order to support out-of-band signaling (separation of control channel and data channel), a
new C-Type, with support for interface ID, was added. The suggested C-Type value is 3.
Hardware signaling accelerator accepts this object Class-Num=3 if C-Type=3. Other-
wise, it passes the message to the software signaling process.
In RSVP, RSVP_HOP object carries the IP address of the RSVP-capable node that
sent this message, it is called PHOP (“previous hop”) in downstream messages (Path mes-
sage) or NHOP (“next hop”) in upstream messages (Resv message). When RSVP-TE is
extended for GMPLS, in order to support the separation of control channel and data chan-
nel, a IF_INDEX TLV is added.
Length Class-Num(3) C-Type(3) TBAIPv4 Next/Previous Hop Address
Logical Interface HandleTLVs
...
29
Hardware signaling accelerator behavior: Pass the message to the software signaling
process if there is more than one TLV.
• IPv4 Next/Previous Hop Address: 32 bits
IP address of the previous LSR (Path message) or next LSR (Resv message), on the
control plane.
hardware signaling acceleratorhardware signaling accelerator behavior: Save this field
in a register and the State table. Previous Hop IP Address received in a Path message
will be used to send the Resv message in the upstream direction. Similarly, the Next
Hop Address received in a Resv message will be used for send PathTear messages dur-
ing LSP release.
• LIH: Save this field in a register, do not process it. This field is required to construct an
RSVP message to the next/previous hop switch and is hence simply stored in the State
table. For messages originating from this transit switch, we use the same LIH (some
constant value).
• IF_ID TLV:
• Length: 16 bits
Indicates the total length of the TLV.
• Type: 16 bits
Indicates type of interface being identified.
Type LengthValue
Type Length Format Description1 8 IPv4 Addr. IPv42 20 IPv6 Addr. IPv63 12 See below IF_INDEX (Interface Index)
30
hardware signaling accelerator behavior: Check the value of this field, and pass the
message to the software signaling process if the value is other than 3.
• Value: variable length, depending on the Length field
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:
Type 3 is used when links are unnumbered [13]; in other words, no IP address is
assigned per link. Therefore one common IP Address, such as a “Router ID,” is used to
identify an LSR, and a locally unique Interface ID identifies a link. Two neighboring
LSRs assign identifiers to their interconnecting data link independently, and exchange
the identifiers by means of Link Management Protocol (LMP) [14]. Types 4 and 5 are
used for a bundled component link as defined in [15].
• IP Address: 32 bits
IP address of the upstream LSR (Path message) or downstream LSR (Resv message),
on the user plane. This address could be different from the IP address on the control
plane.
hardware signaling accelerator behavior: Save this field in a register and the State
table. This address, together with Interface ID, will be used to match the Connectivity
table.
• Interface ID: 32 bits
An interface index.
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)5 12 See below COMPONENT_IF_UPSTREAM (Component interface)
IP AddressInterface ID
Type Length Format Description
31
hardware signaling accelerator behavior: Save this field in a register and the State
table. This interface ID, together with IP Address, will be used to match the Connec-
tivity table.
Multiple TLVs: The general format of the RSVP_HOP object allows for multiple
TLVs for the interface ID specification. If the LSP is bidirectional, as stated in Section
3.3, the hardware signaling accelerator will not handle call setup. For unidirectional
LSPs, it is possible for the RSVP_HOP to carry multiple TLVs. GMPLS requires that
an upstream switch select the interface to use for the LSP and pass this information in
the Path message (within the RSVP_HOP object). This implies that a switch has to
maintain bandwidth availability information for all its outgoing interfaces. Our hard-
ware signaling accelerator only handles calls in which the required bandwidth is avail-
able on one interface as noted in Section 3.3. If this is not the case, and a PATH
message carries an RSVP_HOP in which there are multiple TLVs to identify inter-
faces, then the message is passed on to the software signaling process.
A.4.2.6 SENDER_TEMPLATE
SENDER_TEMPLATE object was initially defined in [8], Class-Num 11, C-Type 1-3.
[7] introduced two new C-Types 7-8 to support LSP tunnel. In our application, C-Type 7
means an IPv4 LSP tunnel.
hardware signaling accelerator accepts this object Class-Num=11 if C-Type=7. Other-
wise, it passes the message to the software signaling process.
The SENDER_TEMPLATE/FILTER_SPEC object specifies the source address of an
LSP. SENDER_TEMPLATE object is carried in Path message, while the FILTER_SPEC
object carried in Resv message. SENDER_TEMPLATE, together with SESSION object,
32
uniquely identifies an LSP.
• IPv4 tunnel sender address: 32 bits
IP address of the sender
hardware signaling accelerator behavior: Save this field in a register and the State
table. IP address of the sender (source IP address) will be used to match a row in the
State table.
• LSP ID: 16 bits
Locally (at the sender) allocated ID for the LSP
hardware signaling accelerator behavior: Save this field in a register and the State
table. It will be used to match a row in the State table.
A.4.2.7 SENDER_TSPEC
SENDER_TSPEC object was initially defined in [8], Class-Num 12, C-Type 2. Refer-
ence [6] added a new C-Type to support SONET/SDH traffic parameters. The value for
this C-Type is not determined yet.
hardware signaling accelerator accepts this object Class-Num=12 if C-Type=TBA.
Otherwise, it passes the message to the software signaling process.
The SENDER_TSPEC/FLOWSPEC object specifies the required traffic parameters of
an LSP. SENDER_TSPEC is carried in Path message while FLOWSPEC is carried in
Resv message. In traditional RSVP, SENDER_TSPEC is opaque, the explanation of this
object is subject to IntServ [16]. RSVP-TE (GMPLS) with extensions supporting SONET/
Length Class-Num(11) C-Type(7)IPv4 tunnel sender address
MUST be zero LSP ID
33
SDH introduced a new C-Type (TBA).
• Signal Type (ST): 8 bits
Indicates the type of Elementary Signal that comprises the requested LSP.
hardware signaling accelerator behavior: The VSC9182 supports three crossconnect
rates: STS-1, STS-3c, and STS-12c. The hardware signaling accelerator will check
this field, and pass the message to the software signaling process if the value is other
than 5 or 6.
• Requested Contiguous Concatenation (RCC): 8 bits
Used to request the optional SONET contiguous concatenation of the Elementary Sig-
nal. Only the first two bits of this field have been defined so far.
Length Class-Num(12) C-Type TBASignal Type RCC NCC
NVC Multiplier (MT)Transparency (T)
Value Type (Elementary Signal)1 VT1.5 SPE/VC-112 VT2 SPE/VC-123 VT3 SPE4 VT6 SPE/VC-25 STS-1 SPE/VC-36 STS-3c SPE/VC-47 STS-1/STM-0 (when transparency)8 STS-3/STM-1 (when transparency)9 STS-12/STM-4 (when transparency)10 STS-48/STM-16 (when transparency)11 STS-192/STM-64 (when transparency)12 STS-768/STM-256 (when transparency)
Flag 1 (bit 1) Standard contiguous concatenation
Flag 2 (bit 2) Arbitrary contiguous concatenation
34
hardware signaling accelerator behavior: VSC9182 can only support standard contigu-
ous concatenation. Check the value of this field, if bit 2 is set, pass the message to the
software signaling process.
• Number of Contiguous Components (NCC): 16 bits
Indicates the number of identical SONET SPEs that are requested to be concatenated.
hardware signaling accelerator behavior: See the MT description.
• Number of Virtual Components (NVC): 16 bits
Indicates the number of signals that are requested to be virtually concatenated.
hardware signaling accelerator behavior: VSC9182 does not support virtual concate-
nation; hence pass the message to the software signaling process if the value is other
than 0.
• Multiplier (MT): 16 bits
Indicates the number of identical signals that are requested for the LSP, i.e. that form
the final signal. These signals can be either identical Elementary Signals, or identical
contiguously concatenated signals, or identical virtually concatenated signals.
hardware signaling accelerator behavior: Save all the fields into registers. Calculate
the final signal bandwidth with the following steps:
• A contiguously concatenated signal (NCC) is built from Elementary Signal (ST).
• The Final Signal is obtained by a multiplication (MT) of Elementary Signal, or the
contiguously concatenated signal obtained from the first step.
Save the Final Signal bandwidth in the State table. If the final bandwidth is greater
than one interface bandwidth, this means the connection will have to be set up via mul-
tiple interfaces. Given our statement in Section 3.3 that the hardware signaling accel-
35
erator will not route an LSP on multiple interfaces, we will pass the message to the
software signaling process if the final signal bandwidth is greater than the largest
bandwidth of any single interface available to the next hop switch (determined through
route lookup).
• Transparency (T): 32 bits
A vector of flags that indicates the type of transparency being requested, i.e., it speci-
fies which fields in the SOH and LOH should be passed through from the ingress
switch to the egress switch of an LSP unmodified [6].
hardware signaling accelerator behavior: Save this field in a register and use it to pro-
gram the switch chip so that the switch can pass on values received in the correspond-
ing header fields unchanged.
A.4.2.8 SESSION
SESSION object was initially defined in [8], Class-Num 1, C-Type 1/2. Reference [7]
defined C-Types 7-8 for LSP tunnel. In our application, C-Type 7, IPv4 tunnel is used.
hardware signaling accelerator accepts this object Class-Num=1 if C-Type=7. Other-
wise, it passes the message to the software signaling process.
Flag 1 (bit 1) Section layer
Flag 2 (bit 2) Line layer
Flag 3 (bit 3) J0
Flag 4 (bit 4) SOH DCC (D1-D3)
Flag 5 (bit 5) LOH DCC (D4-D12)
Flag 6 (bit 6) LOH 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
36
SESSION object specifies the destination address of an LSP. It is carried in Path and
Resv messages.
• IPv4 tunnel end point address: 32 bits
IP address of the destination
hardware signaling accelerator behavior: Save this field in a register and the State
table. Destination IP address will be used to look up the Routing table. Destination IP
address, together with other fields in SESSION and SENDER_TEMPLATE objects,
will be used as a globally unique connection reference.
• Tunnel ID: 16 bits
An ID defining a traffic engineered tunnel, remaining constant over the life of the tun-
nel.
hardware signaling accelerator behavior: Save this field in a register and the State
table. Tunnel ID, together with other fields in SESSION and SENDER_TEMPLATE
objects, will be used as a globally unique connection reference.
• Extended Tunnel ID: 32 bits
hardware signaling accelerator behavior: Save this field in a register and the State
table. Extended Tunnel ID, together with other fields in SESSION and
SENDER_TEMPLATE objects, will be used as a globally unique connection refer-
ence.
Length Class-Num (1) C-Type (7)IPv4 tunnel end point address
Must be zero Tunnel IDExtended Tunnel ID
37
A.4.2.9 STYLE
STYLE object was initially defined in [8], Class-Num 8, C-Type 1. All follow-up pro-
tocols keep it as an mandatory object.
hardware signaling accelerator accepts this object Class-Num=8 if C-Type=1. Other-
wise, it passes the message to the software signaling process.
In traditional RSVP, this object is used to specify the reservation style of a session
(WF, FF, or SE). It is mandatory in Resv/ResvTear Message. In our hardware signaling
accelerator, we will only support the FF reservation style as explained in Section 3.3.
• Flags: 8 bits
Not assigned yet
hardware signaling accelerator behavior: Ignore this field.
• Option Vector: 24 bits
Reservation style of a session. The option vector bits are assigned (from the left) as
follows:
• 19 bits: Reserved
• 2 bits: Sharing control
Length (8 bytes) Class-Num (8) C-Type (1)
Flags Option Vector
Value Type00b Reserved01b Distinct reservations10b Shared reservations11b Reserved
38
• 3 bits: Sender selection control
hardware signaling accelerator behavior: Save this field in a register, check its value,
and pass the message to software signaling process if the last 5 bits carry a number
other than“01010” (FF style).
A.4.2.10 TIME_VALUES
TIME_VALUES object was initially defined in [8], Class-Num 5, C-Type 1. It is kept
as an mandatory object in all follow-up protocols.
hardware signaling accelerator accepts this object Class-Num=5 if C-Type=1. Other-
wise, it passes the message to the software signaling process.
Each RSVP Path/Resv Message contains a TIME_VALUES object specifying the
Refresh Period used to generate refresh message. See Section 3.3 for a discussion on soft
state and refreshes.
• Refresh Period R: 32 bits
Used to set the timer for sending out refreshes. This is used at the receiving end to
compute the time-out value for removing state information (i.e., deleting a connec-
tion).
Value Type000b Reserved001b Wildcard010b Explicit011b-111b
Reserved
Length Class-Num(5) C-Type(1)Refresh Period R
39
hardware signaling accelerator behavior: Save this field in a register, but do not pro-
cess it. The software signaling process reads this parameter for each connection and
processes it.
A.5 Summary
This document describes a subset of the GMPLS RSVP-TE signaling protocol for
implementation in reconfigurable hardware, such as a FPGA. All functionality of the pro-
tocol 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 pro-
tocol [1] showed promise that our approach of implementing time-critical operations in
hardware and complex non-time-critical operations in software is indeed feasible. How-
ever, in migrating from our simple signaling protocol to the GMPLS RSVP-TE signaling
protocol many issues remain to be understood:
• GMPLS RSVP-TE 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.
• Objects in GMPLS signaling messages are organized as Type-Length-Value triplet
instead of fixed position fields.
The GMPLS RSVP-TE has evolved from RSVP to RSVP-TE to RSVP-TE with
extensions for GMPLS networks, such as SONET/SDH and DWDM. This complex proto-
col is now targeting almost all connection-oriented networks both packet-switched and
circuit-switched. This drive impacts almost all fields in parameters within messages. This
impacts the run-time performance since every field received in all messages should be
checked for validity of its value. Furthermore, the size of the executable code for the sig-
40
naling protocol becomes very large posing problems in many specialized processors, such
as Network Processors (NPs) that only have limited 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 to allow the signaling engine to match a message to an existing connection. 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 RSVP-
TE, the connection reference parameter is a combination of five fields in two objects, the
SESSION object and SENDER_TEMPLATE object. It includes the source and destination
IP addresses, tunnel ID and extended tunnel ID, and the LSPID. It is a globally significant
parameter. This makes state tables maintained for connections much harder to search that
if the connection reference was a local number as in OCSP [1].
Next, the TLV structure was designed for flexibility, allowing protocol designers to
add parameters in arbitrary order. But this construct makes parameter extraction in hard-
ware a complex task. The hardware signaling accelerator 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 RSVP-TE, 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
41
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, or retransmission time-outs to resend
signaling messages.
• 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 sig-
naling protocols is well worth attempting. If successful, it will enable many low-latency
interaction-intensive applications for connection oriented networks. At the end of this
study, we hope to either prove that GMPLS RSVP-TE can be implemented in this hard-
ware/software codesign architecture, or to prove the need for a simple signaling protocol
targeted at an individual connection-oriented network.
42
Appendix B: Detailed Description of RSVP-TE
Signaling Procedures
B.1 Introduction
This document is a detailed design document for an FPGA implementation of the
RSVP subset defined in Appendix A. Four messages are processed in the hardware signal-
ing accelerator, Path, Resv, PathTear, and ResvTear. As each message is received, after
checking the checksum to verify that no errors occurred, the module parses out objects and
processes these objects.
As objects are parsed, different fields of the objects are placed in registers. Section 2
lists these registers. In addition, there are a few registers that are set at system initialization
time. We refer to these as “initialization registers.” Values set in these registers control the
functions implemented in the hardware accelerator.
Some numbers are “hardwired” into the implementation instead of being set in initial-
ization registers. For example, the hardware module handles four message types: 1, 2, 5, 6.
Instead of setting these values in an initialization register and having the message proces-
sor compare the message type value carried in an incoming message with these allowed-
message-types, the implementation is hardwired to only accept these four message types.
The reason for this design approach is to achieve low delays and low logic resource usage.
In many such instances, we make design decisions between flexibility and performance.
Most of the signaling message processing consists of reading and writing data tables.
We describe these data tables in Section 3. These tables reflect the functionality defined
for the RSVP subset. For example, the separation of control plane and user plane, allowing
43
multiple interfaces between neighboring switches, allowing for logical links between
neighbors, etc. All data tables are initialized through a software module. Some of them are
only read by the hardware signaling accelerator while others are read and written.
Since RSVP allows objects to be placed in any order within messages, our design
approach is to have object processors start processing objects as they are parsed out mes-
sages. In some cases, the processing of an object will have to wait for another object to be
processed. This is indicated in the flow charts shown in Section 4.
This design is for a signaling engine that will be used in conjunction with a Vitesse
VSC9182 SONET switch chip. The VSC9182 is a switch with 64 OC12 inter-
faces and operates at a crossconnect rate of OC1.
Of all the functionality specified as being supported in the subset, the only change we
made is to not support bandwidth negotiation in the hardware implementation. Thus, the
hardware signaling accelerator will check for the requested bandwidth on all interfaces to
the next hop switch; but if none of them have the requested bandwidth, it will pass the sig-
naling message to the software signaling process for handling. We found this negotiation
process to be too complex for immediate hardware implementation.
Fig. 7 shows the prefixes and suffixes we used in this document.
64 64×
Figure 7. Prefixes and suffixes used in this document.
44
B.2 Registers
Table 1. Registers extracted from messages.
Register Width(bit) Description
Msg_Type 8 Message type, Msg Type in Common HeaderMsg_Len 16 Message length, RSVP length in Common Header
Local_Chksum 16 Locally calculated checksumSend_TTL 8 Send TTL, Send_TTL in Common Header
Src_IP_Addr 32 Source IP address, IPv4 tunnel sender address in SENDER_TEMPLATE object within Path message or FILTER_SPEC object within Resv message.
LSP_ID 16 LSP ID in SENDER_TEMPLATE object within Path message or FILTER_SPEC object within Resv message.
Dest_IP_Addr 32 Destination IP address, IPv4 tunnel end point address in SESSION object within Path/Resv message
Tunnel_ID 16 Tunnel ID in SESSION object within Path/Resv messageExt_Tunnel_ID 32 Extended tunnel ID in SESSION object within Path/Resv message
Pre_IP_Addr_Ctrl 32 Previous IP address on control plane, IPv4 Previous Hop Address in RSVP_HOP object within Path message
Next_IP_Addr_Ctrl 32 Next IP address on control plane, the result of User/Control Map-ping table lookup
LIH 32 Logical Interface Handle in RSVP_HOP object within Path mes-sage
Pre_IP_Addr_User 32 Previous IP address on user plane, IP Address in IF-INDEX TLV within Path message
Pre_IF_ID_User 32 Upstream node output interface ID, Interface ID in IF-INDEX TLV within Path message
Tmp_IP_Addr_User 32 IP Address in IF-INDEX TLV within Resv messageTmp_IF_ID_User 32 Interface ID in IF-INDEX TLV within Resv message
Tmp_IP_Addr_Ctrl 32 IP Address in IPv4 Next Hop Addr. field of the RSVP_HOP object within Resv message
Next_IP_Addr_User 32 Next hop IP address, the result of Routing table lookupSeq_Num 4 Sequence number of the links between two neighboring LSRs.
Incoming_IF_ID_User 32 Incoming interface ID, the result of Incoming Connectivity table lookup
Outgoing_IF_ID_User 32 Outgoing interface ID, the result of Outgoing Connectivity/CAC table lookup
Incoming_PHY_ID 8 Incoming physical interface IDOutgoing_PHY_ID 8 Outgoing physical interface ID
Incoming_Assigned_Timeslots
12 Timeslots assigned to a certain incoming logical link
Outgoing_Assigned_Timeslots
12 Timeslots assigned to a certain outgoing logical link
Incoming_Label(s) 32 Generalized label(s) for the incoming interface, locally allocatedOutgoing_Label(s) 32 Generalized label(s) for the outgoing interface, received from
downstream LSR
45
B.3 Data tables
Fig. 8 is an illustrative network that shows the possibilities accommodated in our sig-
naling accelerator. Fig. 9 shows the signaling message flow while setting up a circuit. It
shows the upstream-downstream relation between switches on the path of a connection.
Signal_Type 8 Signal Type in SENDER_TSPEC object within Path message or FLOWSPEC object within Resv message
RCC 8 Requested Contiguous Concatenation in SENDER_TSPEC object within Path message or FLOWSPEC object within Resv message
NCC 16 Number of Contiguous Concatenation in SENDER_TSPEC object within Path message or FLOWSPEC object within Resv message
NVC 16 Number of Virtual Concatenation in SENDER_TSPEC object within Path message or FLOWSPEC object within Resv message
MT 16 Multiplier in SENDER_TSPEC object within Path messageState 4 Current state of an LSP
Avail_BW 12 Available bandwidth, the result of Incoming CAC table lookup or Outgoing Connectivity/CAC table lookup
LSP_Enc_Type 8 LSP Encoding Type in LABEL_REQUEST object within Path message
Switching_Type 8 Switching Type in LABEL_REQUEST object within Path mes-sage
G-PID 16 Generalized PID in LABEL_REQUEST object within Path mes-sage
Refresh_Period 32 Refresh Period in TIME_VALUES object within Path messageStyle 5 Option vector in STYLE object within Resv message
Table 2. Initialization registers.
Registers/Constant Width(bits)
Init value Meaning
Initialized_LSP_Enc_Type 8 5 SDH ITU-T G.707/SONET ANSI T1.105Initialized_Switching_Type 8 100 Time-Division-Multiplex Capable (TDM)
Local_IP_Addr_User 32 - Local IP address on the user planeLocal_IP_Addr_Ctrl 32 - Local IP address on the control plane
Supported_ST 8 1 The crossconnect rate of the switch - 1 means OC1
Table 1. Registers extracted from messages.
Register Width(bit) Description
46
B.3.1 Routing table
The Routing table, as shown in Table 3, is initialized and maintained by a software
routing process (OSPF-TE for GMPLS). It is read-only to the hardware signaling acceler-
ator. The Next_IP_Addr_User is the user-plane IP address for the next hop switch through
which the destination IP address can be reached. Lookup of this field is a longest prefix
Table 3. Routing table.
Index Return valueDest_IP_Addr Next_IP_Addr_User
Figure 8. Network used for illustrative examples; shows that (i) switches can be con-nected via many user-plane interfaces (ii) logical links can be provisionedbetween non-adjacent switches (iii) a signaling engine may have many signal-ing links leading to the connectionless signaling network (IP network).
Network of IP routers (not necessarily the Internet;could be a specially designed IP network just forsignaling traffic)
Switch
Signalingengine
Switch II
Signalingengine
Client
Switch I
Signalingengine
Switch III
Signalingengine
Logical link
Server
Server-to-clientSONETunidirectionalcircuit
1 234
6 12
34 5
7
Physical interface: 5 Physical interface: 5
6
Physicalinterface: 7
Physicalinterface: 2
Figure 9. Signaling message flow for setting up a unidirectional circuit; SW1 isupstream relative to SW2, and SW2 is upstream relative to SW3 becauseof the direction of the circuit; the data sender initiates circuit setup.
Upstream Downstream
Upstream
SwitchEndDevice SW3
Switch
SW 1
Switch
SW4
Switch
SW2
Switch
SW5
1.Path 2.Path 3.Path 4.Path
EndDevice
7.Resv 6.Resv
5.Resv 8.Resv
9. Connection (circuit or virtual circuit) established
Downstream
47
match because Dest_IP_Addr can be an IP address prefix or a full 32-bit destination
address. In general, a routing table can have alternative next hop switches. However, we
do not implement multiple routing table lookups in the hardware signaling accelerator for
simplicity reasons. This module will attempt only one route; if resources are not available,
it will pass off the message to the software signaling process. For a subsequent release, we
will reconsider this design decision.
B.3.2 Incoming Connectivity table
The Incoming Connectivity table, shown in Table 4, is initialized and updated by a
Link Management Protocol (LMP). It is read-only to the hardware signaling accelerator. It
shows how the interface numbers used by a neighbor maps to an incoming interface num-
ber and the corresponding physical interface. The incoming assigned timeslots column is a
bitmap with 1s for timeslots assigned to this logical interface and 0 for other timeslots.
Using the example shown in Fig. 8, the incoming connectivity table at switch II will
have entries as shown in Table 5. Here we assume that timeslots 1-3 of the physical inter-
face 5 are terminated at switch II while the remaining timeslots 4-12 (we assume all inter-
faces are OC12s given our implementation target, a VSC9182 SONET switch) are used
for the logical link passing through switch II to terminate at switch III. On the other hand,
we assume that all 12 timeslots of physical interface 2 terminate at switch II. In cases
where all timeslots of a physical interface terminate at a switch, we use the same number
for physical interface as for the interface ID used in signaling messages. Otherwise, a log-
Table 4. Incoming Connectivity table.
Index Return valuePre_IP_Addr_User Pre_IF_ID_User Incoming_IF_I
D_UserIncoming_PHY_ID Incoming_Assigned_Ti
meslots
48
ical interface number that maps to a physical interface and timeslots is used in signaling
messages to identify logical links.
B.3.3 Incoming CAC table
The Incoming CAC table, Table 6, shows the available bandwidth for each physical
interface. Using the example shown in Fig. 8, the Incoming CAC table at switch II will
have entries as shown in Table 7.
Avail_BW is a bit-map of the available timeslots on a certain outgoing interface. “1”
means the corresponding timeslot is available while “0” means it is not available. Fig. 10
shows an example of Avail_BW. Here a request for STS-1 can be satisfied but a request
for STS-3c cannot, because even though there are 8 timeslots available, the contiguous
concatenation requirement cannot be satisfied. “Reserve timeslots” means setting the cor-
Table 5. Incoming Connectivity table at switch II in Fig. 8.
Index Return valuePre_IP_Addr_User Pre_IF_ID_User Incoming_IF_I
D_UserIncoming_PHY_ID Incoming_Assigned_T
imeslotsSwitch I IP address 4 2 2 1111 1111 1111Switch I IP address 6 1 5 1110 0000 0000
Table 6. Incoming CAC table.
Index Return valueIncoming_PHY_ID Avail_BW
Table 7. Incoming CAC table at switch II in Fig. 8.
Index Return valueIncoming_PHY_ID Avail_BW
2 1110 0011 10005 1111 1100 0111
Figure 10. Example of Avail_BW.
1 1 0 1 1 0 1 1 0 1 1 0
1: Available0: Not available (reserved)
49
responding bits to “0.” We had the option of storing the Avail_BW bitmap for logical
interfaces instead of physical interfaces. But this could make the data table potentially
quite large. Given that the VSC9182 chip has 64 physical interfaces, by choosing the
physical interface ID for this data table, we can limit the size of the data table and hence
implement the data table within the FPGA’s internal memory. The drawback is that it leads
to an additional AND operation with the Assigned timeslots for a logical link when
searching for bandwidth. In other words, when the CAC table is consulted to check if suf-
ficient resources are available on an interface, after reading the Avail_BW value in the
CAC table, it needs to be ANDed with the assigned timeslots to ensure that a timeslot
assigned to the logical interface is the one being selected.
B.3.4 Outgoing Connectivity table
The Outgoing Connectivity table, Table 8, shows the outgoing interfaces leading to
neighboring switches. It also maintains mapping of logical interface IDs to physical inter-
face IDs and corresponding timeslots. Since a switch may have multiple links to a neigh-
bor, there may be many rows in this data table corresponding to a single
Next_IP_Addr_User. Hence we have the Seq_Num column allowing the hardware signal-
ing accelerator to search this table multiple times until it finds an interface to the neighbor-
ing switch with sufficient available resources or exhausts all interfaces to the neighboring
switches.
An example Outgoing Connectivity table is shown for switch I in Fig. 8. Timeslots 1-3
Table 8. Outgoing Connectivity table.
Index Return valueNext_IP_Addr_User Seq_Num Outgoing_IF_ID_U
serOutgoing_P
HY_IDOutgoing_Assigned_Timeslot
s
50
on physical interface 5 at switch I terminate at switch II while the remaining are routed
through as a logical link to Switch III.
B.3.5 Outgoing CAC table
The Outgoing CAC table, Table 10, is similar to the Incoming CAC table. It shows
available time slots for different outgoing interfaces. Table 11 shows an example Outgo-
ing CAC table.
B.3.6 User/Control Mapping table
Unlike packet-switched MPLS networks, where implicit in-band signaling is used and
there is a one-to-one association between control channels and data links, circuit-switched
networks generally require out-of-band signaling and hence a separation of control chan-
Table 9. Outgoing Connectivity table for switch I in Fig. 8.
Index Return valueNext_IP_Addr_User Seq_Num Outgoing_IF_
ID_UserOutgoing_P
HY_IDOutgoing_Assigne
d_Timeslots Switch II IP address 0 6 5 1110 0000 0000Switch II IP address 1 4 4 1111 1111 1111Switch III IP address 0 7 5 0001 1111 1111
Table 10. Outgoing CAC table.
Index Return valueOutgoing_PHY_ID Avail_BW
Table 11. Outgoing CAC table for switch I in Fig. 8.
Index Return valueOutgoing_PHY_ID Avail_BW
5 1111 1111 10004 0110 0011 11115 1111 1111 1111
Table 12. User/Control Mapping table.
Index Return valueNext_IP_Addr_User Next_IP_Addr_Ctrl
51
nels from corresponding data links. The User/Control Mapping table, Table 12, is used to
map user plane IP addresses of neighboring switches to the corresponding control plane IP
addresses.
Our implementation supports multiple data links between two neighboring LSRs, as
illustrated in Fig. 8. A switch may also have multiple control plane interfaces as shown in
Fig. 8 for switch II. We assume that load balancing of signaling load across multiple con-
trol plane interfaces will be done outside the signaling module and appropriate data down-
loaded to this User/Control Mapping table. We assume that there is only one
Next_IP_Addr_Ctrl associated with each next-hop switch.
B.3.7 State table
The State table, as shown in Table 13, is the most complex of all the data tables. The
State table consists of two parts: the index part, which includes the Src_IP_Addr, LSP_ID,
Dest_IP_Addr, Tunnel_ID, Ext_Tunnel_ID, and uniquely identifies an LSP, and a return
value part, which consists of many parameters about the LSP. The appendix explains our
Table 13. State table.
Index (Global connection reference)Return value
Control plane User plane
Src_IP_Add
r
LSP_ID
Dest_IP_Add
r
Tunnel_ID
Ext_Tunnel_ID
Pre_IP_Addr_Ctr
l
LIH
Next_IP_Addr_Ctrl
Pre_IP_Addr_User
Pre_IF_ID_User
Incoming_Assigned_Times
lots
Outgoing_Assigned_Times
lots
Return value (con’t)
User plane (con’t)
Incoming_IF_ID_
User
Incoming_PHY_ID
Incoming_Label(s)
Next_IP_Addr_User
Outgoing_IF_ID_
User
Outgoing_PHY_I
D
Outgoing_Label(s)
Traffic_Spec
State
52
reasoning for using the five-tuple index as the global connection reference.
Unlike in “stateless” connectionless networks, in connection-oriented networks, a
switch needs to maintain state information for each LSP. We defined three states for an
LSP as shown in Fig. 11. Before a Path message arrives, the LSP does not exist, and is
hence in the NULL state. After a Path message is received, a next hop IP address is deter-
mined and resources are reserved. The LSP then enters the RESERVED state. When the
Resv message arrives, timeslots (labels) are allocated and the LSP enters the ESTAB-
LISHED state.
The reason we chose the values 1, 2 and 4 for the numerical values of the states is
because we chose the “one-hot” style for the State register. There are three common ways
for encoding information such as State in a register: (i) Binary, which uses all possible
combinations. For example, if there are 8 different states, we would use 3 bits to represent
these 8 states. The benefit of this style is that it the size of the State register is small. The
drawback is that this style needs a decoder. (ii) One-hot, which uses the same number of
bits as the number of states. Using the same example, if there are 8 states, we would need
an 8-bit register. Each bit corresponds to a state. The benefit is that no decoder is required
and hence updating the State register will be faster than with the binary style. Given that
FPGAs have an abundance of registers, the one-hot style is popular. (iii) Gray-coding,
which uses the Gray-code to represent different states. The benefit is that it needs only a 1-
bit change between two states, which avoids possible glitches. The drawback is that it is
slower than the one-hot style and consumes more resources than the binary style.
53
An example entry is shown in Table 14 for the connection from the server to the client-
Table 14. An example state table entry at switch II for the connection shown in Fig. 8.
Index (Global connection reference)Return value
Control plane Data plane
Src_IP_
Addr
LSP_ID
Dest_IP_Addr
Tunnel_ID
Ext_Tunnel_ID
Pre_IP_Addr_Ctrl
LIH Next_IP_Addr_Ctrl
Pre_IP_Addr_User
Pre_IF_ID_User
Incoming_Assigned_Timesl
ots
Outgoing_Assigned_Timesl
ots
Server’s IP
address
1 Cli-ent’s IP
address
1 1 Switch I’s
Con-trol
plane IP
address
1 Switch III’s Con-trol
plane IP
address
Switch I’s
user-plane
IP addres
s
6 111000000000
111000000000
Return value (con’t)
Data plane (con’t)
Incoming_IF_ID_
User
Incoming_PHY_ID
Incoming_Label(s)
Next_IP_Addr_User
Outgoing_IF_ID_
User
Outgoing_PHY_I
D
Outgoing_Label(s)
Traffic_Spec
State
1 5 Switch I’s
user-plane
IP addres
s
4 7 1 OC1 2
Figure 11. State transition diagram.
NULL(1)
ESTABLISHED(4)
RESERVED(2)
Path
Error
Path
Tear
/Res
vTea
r
Resv
54
shown in Fig. 8 at switch II. We assume that the server-to-client connection shown in
Fig. 8 is routed on the logical link from 6-1 between switch I and switch II and then con-
nected to a timeslot on the logical link from 4-5 between switch II and switch III. It shows
the entry when the connection is in the RESERVED state, 2. This means a Path message
has been received and processed and another Path message sent on to the next (down-
stream) switch but a Resv message is not yet received. Therefore the incoming and outgo-
ing labels are not yet assigned.
B.4 Procedures
When a message is parsed, fields from within objects are stored into registers. For
field names consult the message specifications in Appendix A. For register names, see
Section 2. The notation used to represent a data table lookup is Output registers<-F
(Data table name, Input registers). The function F represents a lookup of the data table
identified by the first argument. The row corresponding to which the current values in the
Input registers (identified in the arguments to function F) match the values in the corre-
sponding columns of the data table is selected through this lookup. We chose the same
names for registers and columns in data tables. The values returned from the data table
lookup is stored in the Output registers.
Four actions are required to set up a connection: (i) look up routing table for next hop,
(ii) run CAC algorithms to determine if enough resources are available, (iii) select avail-
able timeslots/wavelengths, and (iv) program the switch fabric. The first step has to be
performed in the forward direction when a Path message is received. Resource reservation
for multicast sessions in RFC 2205 was designed to be handled in the reverse direction
because a receiver joins a multicast tree when needed. This implies that a switch should
55
maintain resource availability for its incoming interfaces and carry out steps 2, 3, 4 in the
reverse direction. However, in GMPLS networks, because of the introduction of a separa-
tion of control-plane and user-plane interfaces, reference [3] states that the upstream node
needs to select the outgoing interface for the connection. This means a switch should keep
resource availability for its outgoing interfaces, and should perform CAC to check that
there are sufficient resources before selecting an interface (see Outgoing Connectivity/
CAC table in Section 3.4).
According to RFC 3209, the downstream switch selects the label though the upstream
switch can suggest a label in the Path message. GMPLS allows for the Path message to
carry a suggested label and/or label set objects. However, in the subset we defined for
hardware implementation, we do not implement these optional objects. Hence, in our
implementation, steps 3 and 4 are handled in the reverse direction when a Resv message is
received.
Figs. 12-36 provide the detailed flow charts for processing the four signaling messages
and their associated objects. We use different notation as follows:
1. Names of fields within RSVP message objects are identified in italics
2. Register names, data table names and messages are identified in boldface.
To parse out objects and fields within objects, we refer implementors to Appendix A,
which specifies the exact bit locations of object fields. RSVP objects follow the TLV (Tag-
Length-Value) structure. Hence to parse out the value in a field within an object, in order
to copy the value into a register, the length field should be read first to identify the location
of the appropriate bits (as specified in Appendix A).
We note that there is potential for a conflict to arise given the current GMPLS signal-
56
ing specifications in which the Suggested Label object in Path message is left as optional.
Consider the following scenario. An outgoing logical interface from a switch has four
assigned timeslots, say 111 100 000 000, out of a possible 12 timeslots on an OC12 inter-
face. Say the first call requests an OC1; the upstream switch tentatively reserves the first
time slot. It sets the Avail_BW in the Outgoing CAC table for the corresponding physical
interface to be 011 100 000 000 (ignore the values in the last 8 bits). This update is shown
in Fig. 14. Say a second call, one that requests an OC3c arrives next, and needs to be
routed on this same outgoing logical interface. The switch will then make a tentative reser-
vation of the remaining time slots and change Avail_BW to all zeros. If the downstream
switch returns a Label for this interface in its Resv message different from time slot 1 for
the first call, say it selects time slot 2, then the second call for which a tentative reservation
was made can no longer be accommodated because the latter requires a concatenated
assignment. This will result in an error condition needing software intervention. Hence,
we recommend the addition of the Suggested Label object in Path messages to force the
downstream switch to select an appropriate label. This is the result of the IETF community
starting with RSVP, which was developed as a signaling protocol for receiver-initiated
additions to a multicast tree, and growing it into a signaling protocol for GMPLS net-
works. In GMPLS networks, where hard resource reservations of timeslots and wave-
lengths are necessary, a reservation needs to be made in the forward direction. In this
version of this document, we have not included the Suggested Label, but will do so in a
subsequent release or find another solution to this problem.
57
Figure 12. Processing of common header.
Figure 13. Processing of Path message.
58
Figure 14. SESSION and SENDER_TEMPLATE objects in Path message.
59
Figure 15. Processing of RSVP_HOP object in Path message.
60
Figure 16. Processing of TIME_VALUESobject in any message.
Figure 17. Processing of SENDER_TSPEC object in Path message.
61
Figure 18. Processing of LABEL_REQUEST objectin Path message.
62
After processing all the objects in a Path message, the state table is updated by copy-
ing values from the registers shown in the right-hand column of table in the following
manner:Table 15. Updating State table after processing a Path message.
State table column Register
Src_IP_Addr Src_IP_Addr
LSP_ID LSP_ID
Dest_IP_Addr Dest_IP_Addr
Tunnel_ID Tunnel_ID
Ext_Tunnel_ID Ext_Tunnel_ID
Pre_IP_Addr_Ctrl Pre_IP_Addr_Ctrl
LIH LIH
Next_IP_Addr_Ctrl Next_IP_Addr_Ctrl
State State (=2)
Pre_IP_Addr_User Pre_IP_Addr_User
Figure 19. At the end of Path message processing.
63
To create the outgoing Path message, the hardware signaling accelerator should con-
struct a message following the details of the object formats in Appendix A. The values for
all these fields needed should be copied from corresponding registers. The register names
are obvious for all objects except the RSVP_HOP object. The registers to be used to con-
struct the RSVP_HOP object are shown in Fig. 20.
The destination IP address for the Path message should be obtained from the
Next_IP_Addr_Ctrl register.
Pre_IF_ID_User Pre_IF_ID_User
Incoming_IF_ID_User Incoming_IF_ID_User
Incoming_PHY_ID Incoming_PHY_ID
Incoming_Label(s) NULL
Incoming_Assigned_Timeslots
Incoming_Assigned_Timeslots
Next_IP_Addr_User Next_IP_Addr_User
Outgoing_IF_ID_User Outgoing_IF_ID_User
Outgoing_PHY_ID Outgoing_PHY_ID
Outgoing_Label(s) NULL
Outgoing_Assigned_Timeslots
Outgoing_Assigned_Timeslots
Traffic_Spec <Signal_Type, RCC, NCC, NVC, MT>
Table 15. Updating State table after processing a Path message.
Figure 20. Assemble new Path message.
64
Figure 21. Processing of Resv message.
65
Figure 22. Processing of SESSION and FILTER_SPEC objects in Resv message.
66
** Extract from Page 39, RFC 2205 [8]: “The NHOP (i.e., the RSVP_HOP) object
contains the IP address of the interface through which the Resv message was sent and the
LIH for the logical interface on which the reservation is required.”
** Extract from Page 22, RSVP-TE for GMPLS [4]: “A node receiving one or more
TLVs in a Path message saves their values and returns them in the HOP objects of subse-
quent Resv messages sent to the node that originated the TLVs.”
Figure 23. Processing of RSVP_HOP in Resv message.
67
Figure 24. Processing of STYLE objectin any message.
Figure 25. Processing of FLOWSPEC object in Resv message.
68
Figure 26. Processing of LABEL object in Resv message.
69
Figure 27. At the end of Resv message processing.
Figure 28. Assemble new Resv message.
70
The RSVP_HOP object in PathTear and ResvTear message and the FLOWSPEC
object in ResvTear message can simply be discarded. We could process the object fields
and compare the values with those stored for the connection in the state table. This may
perhaps be implemented but is omitted here in the detailed procedure descriptions because
it is relatively straightforward.
Figure 29. Processing of PathTear message.
71
Figure 30. Processing of SESSION and SENDER_TEMPLATE objectsin PathTear message.
72
Figure 31. At the end of PathTear message processing.
Figure 32. Assemble new PathTear message.
73
Figure 33. Processing of ResvTear message.
74
Figure 34. Processing of SESSION and FILTER_SPEC objects inResvTear message.
75
Figure 35. At the end of ResvTear message processing.
Figure 36. Assemble new ResvTear message.
76
Appendix C:
C.1 Comparison of RSVP-TE and OCSP
In this section, we compare RSVP-TE to OCSP (Optical Circuit-switched Signaling
Protocol) that we designed for SONET networks [1], and clarify the definition of certain
terms.
Table 16. Mapping parameters of OCSP to RSVP fields in objects.
Message Optical Circuit Signaling Protocol (OCSP) RSVP
Setup and Setup-suc-cess (OCSP); Path and Resv (RSVP)
Connection reference Tunnel ID /Ext. Tunnel ID and IPv4 tunnel end point address within SESSION object/LSP ID and IPv4 tunnel sender address within SENDER_TEMPLATE/FILTER_SPEC object
Destination IP address IPv4 tunnel end point address within the SES-SION object
Source IP address IPv4 tunnel sender address within SENDER_TEMPLATE/FILTER_SPEC object
Previous node’s IP address IPv4 Next/Previous Hop address within RSVP_HOP object
Bandwidth Traffic parameters within SENDER_TSPEC/FLOWSPEC
Interface number Interface ID in IF_ID RSVP_HOP object (3209)Timeslot number Generalized LABEL objectTTL RECORD_ROUTE object is used for loop detec-
tion (like PATH_VECTOR in LDP). This is optional, which means it will be handled in soft-ware. Therefore, we have no easy way of detecting loops on the fast path. RSVP was originally designed to be added to an IP router and the rout-ing table used for IP forwarding is the same rout-ing table used for flow setup; but we could be running a GMPLS RSVP-TE engine in a SONET XC which does not have a collocated IP router. In this case, there is no provision to detect loops dur-ing call setup.
Checksum RSVP_ChecksumNo corresponding parameter TIME_VALUES object
77
C.2 Explanation for connection reference
The signaling engine at a switch needs to be able to identify a connection when first
created in order to associate subsequent signaling messages arriving at the switch with
connections. This is typically called a “connection reference.” Connection references can
be local or global. Local numbers are unique to a switch, while global connection refer-
ences identify a connection globally across all switches. Usage of local connection refer-
ences leads to performance-friendly implementations because the state table, which is
indexed on the connection reference, is easier to search than if connection references are
global. Nevertheless, RSVP-TE chose a global connection reference.
The SESSION object in RSVP carries destination port and as explained in Section 1.1
of RFC2205, the destination port provides for further multiplexing (along with IP protocol
ID). In other words, a host can have many connections set up to a destination IP address.
The actual destination is a process inside the end host. In RFC 3209, the Tunnel ID field
replaces the Destination Port of RFC 2205 in the SESSION object. This means that the
Tunnel ID is a field used for further demultiplexing at the destination. Does this mean it
can be ignored in the transit switches? No, because it is used to identify the connection. It
forms a connection reference number in conjunction with LSP ID in the sender template
object along with source and destination IP addresses.
Release and Release-Con-firm (OCSP); PathTear and ResvTear (RSVP)
Cause No corresponding parameterConnection reference (Prev) Tunnel ID /Ext. Tunnel ID and IPv4 tunnel end
point address within SESSION object & LSP ID and IPv4 tunnel sender address within SENDER_TEMPLATE/FILTER_SPEC object
Connection reference (own)
No corresponding parameters RSVP_HOP in both and STYLE, FLOWSPEC in ResvTear
Table 16. Mapping parameters of OCSP to RSVP fields in objects.
Message Optical Circuit Signaling Protocol (OCSP) RSVP
78
The SENDER_TEMPLATE object identifies the source of the connection. It not only
carries the IP address of the sender but also the source port number in RFC 2205. In RFC
3209, the source port was replaced by an LSP ID. The question is what is the difference
between an LSP and a tunnel?
RFC 3031 states the difference between an LSP and an LSP tunnel. An LSP tunnel is
like an ATM VPC with another LSP passing through it such as an ATM VCC. In other
words, using label stacking, you can create an LSP tunnel, which is itself an LSP, but
when this LSP is on the end-to-end path of another LSP, then it becomes an LSP tunnel.
The general definition of LSP tunnel given in 3209 that it is “an LSP which is used to tun-
nel below normal IP routing and/or filtering mechanism” suggests that even a one-level
LSP between two IP routers is an LSP tunnel. Then strictly speaking, the only situation
under which an LSP is not an LSP tunnel is if the LSP carries non-IP traffic! For example,
in our end-to-end Ethernet/EoS circuits if we run ST (Scheduled Transfer) protocol over a
SONET LSP, then the LSP is not an LSP tunnel.
We clarify a few more terms below:
1. What is a traffic trunk? This is defined in RFC 2702. “A traffic trunk is an aggrega-
tion of traffic flows of the same class which are placed inside an LSP.” Traffic trunks are
compared to ATM virtual circuits in this RFC.
3. What is a Traffic engineered LSP? We could not find this term in any RFC. We
coined it to be an LSP that has allocated resources to meet certain QoS requirements. On
page 7 of 3209 there is a statement that LSP tunnels can be established with or without
QoS requirements. An LSP or a LSP tunnel can indeed be established without the CAC/
resource reservation phase. The phrase “CR LSP” is used instead of “traffic engineered
79
LSP” in the CR-LDP specification. It says “constraint based routing” is more than just
source routing (explicit routing). The latter is a subset of the more general concept of con-
straint based routing. The set of QoS requirements for an LSP is viewed as a constraint
taken into consideration when setting up the LSP.
4. Traffic Engineered Tunnel (TE Tunnel): This is defined on page 6 of 3209 as “A set
of one or more LSP tunnels which carries a traffic trunk.” Can we assume that to carry a
“traffic trunk” through an LSP, the LSP should be traffic engineered? If so, the TE Tunnel
is a set of one or more TE LSP tunnels.
RFC 3209, page 6, describes “a traffic trunk being spread over multiple paths.” It
states that to identify and associate LSP tunnels used within a TE tunnel, we need the tun-
nel ID, which is carried in the SESSION object and the LSPID, which is carried in
SENDER_TEMPLATE and FILTER_SPEC. This means that to set filters at the LSRs
both these IDs need to be associated with labels. Unlike in RSVP (2205) where the source
port specified in the FILTER_SPEC is used to directly filter out packets that need a spe-
cific type of treatment (QoS), here the FILTER_SPEC carries an LSP ID but the packets
themselves carry labels. This is because labels change at each switch, whereas source port
does not. Hence we need to use some other ID during call setup, and this is LSP ID. There-
fore the combination of LSP ID and Tunnel ID along with source IP and destination IP
address is indeed the connection reference. It is a global connection reference! Clearly, in
Figure 37. LSP tunnels, LSPs, TE tunnels.
If an end host asks for 7VT1.5 to carry an Ethernetsignal, each VT1.5 could be carried on a separatepath. All have the same tunnel ID, but different
LSP tunnel
end hostor IProuter
LSP1
LSP2
LSP1+LSP2 = TE tunnel
end hostor IProuter
LSP IDs.
80
choosing global connection references instead of local connection reference, attention was
not paid to performance aspects.
Also, the reason for having both a tunnel ID and and an LSP ID is that there is no con-
cept of grouping virtual circuits set up at the IP level with RSVP. This feature can be used
to set up a virtual concatenated SONET signal with individual signals routed on different
paths.
C.3 Explanation for Style
Depending on the style of resource reservation, there is a correlation between
FILTER_SPEC and FLOWSPEC. FLOWSPEC specifies the QoS requirements for that
receiver. FILTER_SPEC indicates whether multiple senders can send on to the same flow
(shared explicit reserved resources), data from all senders are shared on the same flow res-
ervation (shared wildcard) or whether each sender has a unique reservation (Fixed Filter -
FF) reservation style. The FILTER_SPEC allows routers to filter out appropriate packets
and give them the reserved resources. In FF style, one FLOWSPEC is associated with
each FILTER_SPEC. Therefore FILTER_SPEC carries not only the source address but
also the source port. Remembering that in RSVP Path messages are advertisements for
traffic being multicast (which then allows receivers to ask for reservations for a leg of the
multicast session toward them from the main tree), the Path message carry
SENDER_TSPEC - traffic characteristics of the data being sent by specific senders. In
addition, SENDER_TEMPLATE carries a source port to indicate which application run-
ning on this UDP port is generating multicast traffic with the SENDER_TSPEC character-
istics.
81
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), “Generalized Multi-Protocol Label Switching (GMPLS) Architec-
ture,” IETF RFC 3945, Oct. 2004.
[3] L. Berger (editor), “Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional Description,” IETF RFC 3471, Jan. 2003.
[4] L. Berger et al., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Re-
source ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” IETF RFC
3473, Jan. 2003.
[5] P. Ashwood-Smith (editor), L. Berger, “Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP)
Extensions,” IETF RFC 3472, Jan. 2003.
[6] E. Mannie (editor), D. Papadimitriou, “Generalized Multi-Protocol Label Switching
(GMPLS) Extensions for SONET and SDH Control,” IETF RFC 3946, Oct. 2004.
[7] D.Awduche et al., “RSVP-TE: Extensions to RSVP for LSP Tunnels,” IETF RFC
3209, December 2001
[8] R.Braden et al., “Resource ReSerVation Protocol (RSVP)-Version 1 Functional Spec-
ification,” IETF RFC 2205, Sept. 1997
[9] E. 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-sdh-extensions-03.txt, June 2002.
[10] D. Papadimitriou (editor) et al., “Generalized MPLS (GMPLS) Signaling Extensions
82
for G.709 Optical Transport Networks Control,” IETF Internet Draft, draft-ietf-ccamp-
gmpls-g709-08.txt, Sept. 2004.
[11] P. De Dobbelaere, K. Falta, S. Gloeckner, S. Patra, “Digital MEMS for optical switch-
ing,” IEEE Communications Magazine, Volume 40, Issue 3, March 2002.
[12] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, “RSVP Refresh
Overhead Reduction Extensions,” RFC 2961, April 2001.
[13] K. Kompella, Y. Rekhter, “Signalling Unnumbered Links in RSVP-TE,” IETF Internet
Draft, draft-ietf-mpls-rsvp-unnum-07.txt, July 2002.
[14] J. P. Lang (editor), “Link Management Protocol (LMP),” IETF Internet Draft, draft-
ietf-ccamp-lmp-10.txt, Oct. 2003.
[15] K. Kompella, Y. Rekhter, L. Berger, “Link Bundling in MPLS Traffic Engineering,”
IETF Internet Draft, draft-ietf-mpls-bundle-04.txt, July 2002.
[16] J. Wroclawski, “The Use of RSVP with Integrated Services,” RFC 2210, Sept. 1997.