dissertation (appendix)mv/research/hwsig/papers/appendix.pdf · appendix a: specification of a...

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.


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


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.


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.



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.



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.



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


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


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-


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


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


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.



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


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.


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


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.



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.



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



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



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.

dissertation (appendix)mv/research/hwsig/papers/appendix.pdf · appendix a: specification of a...

Documents