Specification of a Subset of RSVP-TE

Transcription

1 Specification of a Subset of RSVP-TE for Hardware Implementation Version 0, Revision 2 November, 2002 Haobo Wang, Malathi Veeraraghavan, Tao Li Polytechnic University haobo_w@photon.poly.edu November 6,

2 Abbreviations and Acronyms AIS Alarm Indication Signal ASIC Application Specific Integrated Circuit ATM Asynchronous Transfer Mode BLSR Bidirectional Line Switched Ring 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 LSC Lambda Switch Capable LSP Label Switched Path LSR Label Switched Router MEMS MicroElectro-Mechanical Systems MPLS MultiProtocol Able Switching OCSP Optical Circuit Signaling Protocol OSPF Open Shortest Path First PDU Protocol Data Unit 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 URL Uniform Resource Locator VCI Virtual Channel Identifier VPI Virtual Path Identifier WDM Wavelength Division Multiplexing November 6,

3 1. Introduction 1 Signaling protocols in switches are primarily implemented in software for two reasons. First, signaling protocols are quite complex with many messages, parameters and procedures. Second, signaling protocols are updated often requiring a certain amount of flexibility for upgrading field implementations. While these are two good reasons for implementing signaling protocols in software, there is an associated performance penalty. Even with state-of-the-art processors, software implementations of signaling protocols are rarely capable of handling over 1000 calls/sec. Correspondingly, call setup delays per switch are in the order of milliseconds. Applications of connection-oriented networks are limited by this call setup overhead. The goal of this project is to implement a signaling protocol, or at least a part of the protocol, in hardware to decrease call setup delays and increase call handling throughputs. In [1], we defined a signaling protocol for Synchronous Optical NETwork (SONET) networks, 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 Circuits (ASICs) at the opposite end of this spectrum. FPGAs can be reprogrammed with updates as signaling protocols evolve while significantly improving call handling capacities relative to software implementations. To handle the complexity issue, we define a subset of the signaling protocol specific to the target architecture and applications for hardware acceleration. This subset should include all time-critical operations. Non-timecritical operations (for example, processing of optional parameters, error handling, etc.) are relegated to software. When we defined our signaling protocol for SONET networks [1] in 1999, the Generalized MultiProtocol Label Switching (GMPLS) effort in the IETF was just getting underway. Now the GMPLS working group has generated many specifications [2]-[6]. Among these specifications are adaptations of Resource ReSerVation Protocol - Traffic Engineering (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 hardware 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- 1. This work is sponsored by a NSF grant, , and by NYSTAR (The New York Agency of Science, Technology and Academic Research) through the Center for Advanced Technology in Telecommunications (CATT) at Polytechnic University. November 6,

4 menting only a subset of the protocol in hardware and the remaining portion in software for execution on a general-purpose processor. To achieve high performance, we need to select specific messages and parameters carefully so that a high percentage of signaling messages can be handled by the hardware module. This design document describes a subset of 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 this paper. 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 signaling specification consists of a signaling functional description [3], RSVP-TE extensions [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 Liberal (typical), and conservative label retention mode Request, traffic/data, and topology driven label allocation strategies Explicit routing (typical), and hop-by-hop routing Before describing these procedures, we define the terms downstream and upstream. Since connections 1 are unidirectional, a switch SW1 is an upstream neighbor of another switch SW2 if data flows from SW1 to SW2 on the connection after it is established. Likewise, SW2 is a downstream neighbor of SW1. In downstream-on-demand label allocation mode, a switch does not allocate a label unless its upstream neighbor explicitly requests a label. This is in contrast to downstreamunsolicited label allocation mode where a switch can initiate the allocation and distribution of a label without being explicitly asked to do so. In GMPLS, only the former procedure is allowed. Ordered control implies that a switch does not allocate labels for a connection until it has an established label leading to the destination in question on its downstream side. In 1. We use the generic term connections interchangeably with the term Label Switched Paths (LSPs). November 6,

5 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 Figure 1. This mode of control is in contrast to independent 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. Switch SW SW Resv 5.Resv 6.Resv 7.Resv End Switch Switch Switch End Device SW 1 SW 2 SW Device 3 1.Path 3.Path 4.Path 2.Path FIGURE 1. Ordered control The label retention mode has to do with whether or not a connection to a destination D is retained even when there is a change in the routing data for D. To set up a connection, routing data is consulted with the destination address of the connection to obtain a nexthop address toward which to route the connection. Furthermore, resources are allocated and labels are assigned for the connection. Following such a setup if the routing data for the connection changes, indicating an alternate path to the destination than the one used while setting up the connection, in liberal label retention mode, the connection stays established until explicitly released, whereas in conservative label retention mode, the connection is released on the old path and reestablished via the new next hop node. 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 network at the IP layer and initiates the set up of a connection. Topology changes in the connection-oriented network, such as link failures, could trigger a reestablishment of connections. Finally, the type of routing used can be explicit or hop-by-hop. In explicit routing, the ingress switch determines the end-to-end route and places this as a parameter in the Label Request Message. This is referred to as source routing in the general literature. In contrast, with hop-by-hop routing, each switch determines the next-hop switch toward which to route a connection. Both modes are allowed in GMPLS networks. The GMPLS signaling specifications define the following eleven new features for supporting switching technologies other than packet switching [2]: Switch 9. Connection (circuit or virtual circuit) established) November 6,

6 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 secondary LSP indication 9. Explicit routing with explicit label control for a fine degree of control 10.Technology-specific traffic parameters 11.LSP administrative status handling GMPLS is highly generic since it caters to a wide-variety of networks, both packet- and circuit-switched, and hence has many options. Only building blocks 1, 2 and 10 are mandatory. Typically building blocks 6 and 9 should be implemented. Building blocks 3, 4, 5, 7, 8 and 11 are optional. The GMPLS signaling used in a typical SDH/SONET switching network would include building blocks 1, 2, 6, 9, 10 and 11. Since SDH/SONET switching network has already implemented protection and restoration functions, building blocks 7 and 8 are optional [2]. 3. Our architecture and applications As described in Section 2, there are many versions of 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 parameters within messages. For example, the specification of the address field identifying the destination address of the connection allows for different address families, IPv4, IPv6, telephony E.164, ATM End System Addresses, etc. This is just one example. A majority of the fields can be assigned different values depending on the specific architecture and applications being targeted. This goal of developing a flexible signaling protocol thus operates against our goal of implementing a high-performance signaling engine. Our solution to this problem is to define a subset of the signaling protocol for hardware implementation based on a specific target architecture and applications. In this section, we define our target architecture and applications. 3.1 Architecture Our target switch is a SONET switch operating at an STS-1 cross-connect rate. The reason we choose SONET switches to demonstrate our high-performance signaling engine November 6,

7 is as follows. First, we decided to use a circuit switch instead of a packet switch because signaling protocol messages for Circuit-Switched (CS) networks carry fewer parameters than for Connection-Oriented (CO) Packet-Switched (PS) networks. For example, signaling messages for CO PS networks carry rate information and burstiness parameters in the traffic descriptor, and delay and loss requirements, while in CS networks, signaling messages only carry a peak (or constant) rate traffic descriptor. Second, among the various circuit switches available, we eliminated optical WDM 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 messages. Therefore, we plan on using GbE links for the signaling links. This means a common control channel carries signaling messages for all interfaces between two switches. Figure 2 illustrates the switch architecture. The user-plane line cards and switch fabric constitute a SONET switch. The signaling engine shown in the control-plane unit has a Hardware signaling module, which will be implemented in reconfigurable hardware such as FPGA, and a Software signaling process, which is a process running on a general-purpose microprocessor. Other software processes such as the illustrated Routing process will be needed. Maintenance and management software is omitted for clarity from Figure 2. The input and output signaling interfaces are GbE links. Control plane Routing process up Signaling process Input signaling Interface NIC NIC Signaling Hardware Accelerator NIC NIC Output signaling Interface Input Interface User plane Line card Line card Switch Fabric Line card Line card Output Interface FIGURE 2. Unfolded view of a switch The network architecture consists of many SONET switches. We allow for multiple SONET interfaces between two SONET switches. The network can have an arbitrary topology. The endpoints of this network that generate requests for circuits are allowed to be IP routers or end hosts with IP addresses assigned to their SONET interfaces. Thus, the only addressing scheme supported is IPv4. We allow for non-neighboring SONET November 6,

8 switches to be logically connected with fat pipes that traverse intermediate switches as illustrated in Figure 3. End Device 1 SW2 SW6 End Device 2 SW1 SW3 SW4 SW5 The LSP between End Device 1 and End Device 2 Physical Link Traffic Engineering Link ("fat pipe") SW# SONET Switch FIGURE 3. Network architecture 3.2 Applications We target this specification of the RSVP-TE subset for two applications. The first application is restoration in a SONET ring. When a failure occurs, the ends of paths traversing the failed link detect the failure through signals such as path-ais (Alarm Indication Signal) and initiate restoration procedures. All restoration is on unidirectional circuits. For example, if the ring is a Unidirectional Line Switched Ring (ULSR), then typically only one direction of the circuits need to be restored after the first failure (in the example shown in Figure 4, only the 4-3 circuit needs restoration when the span from 1 to 2 fails, while the 3-4 circuit is intact). In the case of a Bidirectional Line Switched Ring (BLSR), circuits will be lost in both directions. However, with this choice of the RSVP- TE subset, the circuit in each direction is restored with a separate set of signaling messages. Figure 4 shows an example ULSR. If the span from node 1 to 2 fails, then router 4 will initiate the restoration of the circuits from 4 to 2 and 4 to 3. Router 1 will initiate restoration of the circuits from 1-2, 1-3 and 1-4. Router 3 will initiate restoration for the circuits from 3-2. Thus the sending end of the unidirectional circuits sends the initiating Path message. This allows for it to start sending data when it receives the Resv message after the ordered downstream-on-demand setup. November 6,

9 R1 ADM1 R4 ADM4 ADM2 R2 ADM3 R3 FIGURE 4. Ring restoration application The second application is for file transfers. We assume that the client and server hosts are connected by two types of end-to-end paths: a TCP/IP path and an end-to-end SONET circuit as shown in Figure 5. In this application, the client opens a TCP connection on the IP network and sends a URL (if http is the application layer protocol) or a get request (if ftp is the application layer protocol). The server decides whether to send the file on the TCP/IP path or whether to set up a SONET circuit for the file transfer. This decision could be based on the size of the file to be transferred, the availability of an end-to-end SONET path to the client, etc. If the server decides to use a SONET circuit, it generates a 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 initiator of the Path message. 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 ResvTear. November 6,

10 TCP/IP path SONET circuit Server Client LEGEND IP Router 3.3 Functionality defined in this subset CO Switch FIGURE 5. File transfers between the Server and Client To support the above-described architecture and applications, we identify a subset of signaling functions that will be handled by a hardware signaling module. Remaining functions will be handled by a software signaling process. Functions to be implemented in the hardware signaling module 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 application, 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 different 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 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 signaling module. November 6,

11 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 significant. 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 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 circuit 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 module to store these values, but processing of refresh messages and checking for time-outs will be relegated to the software signaling 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 module, we do not process messages carrying these optional fields due to difficulties in implementing timers in hardware. However, this is the most important set of optional parameters to implement in a subsequent hardware signaling module because of its implication on reliable transport. 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 or IP routers). Packet losses in such switches will result in lost RSVP messages. Building in reliable transport is important for signaling messages. The hardware signaling module supports only the Fixed-Filter (FF) reservation style with one flow descriptor. For our applications, we assume all connections are point-topoint. For point-to-point connections, only the FF style is applicable. Furthermore, we limit the number of flow descriptors handled by the hardware signaling module 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. November 6,

12 The hardware signaling module supports the concept of separation of control plane and user plane interfaces. 4. Subset specification for the hardware signaling module 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 introduced, some are not applicable to new applications, some once optional are now mandatory. 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-timecritical, 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. 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 introduced 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 hardware. 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 used meta-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 items The BNF implies an order for the items. November 6,

13 4.1.1 Common header Common header is defined in [8], page 32. Vers Flags Msg Type RSVP Checksum Send_TTL (Reserved) RSVP Length Vers: 4 bits Protocol version number. This is version 1. Hardware signaling module 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 Value Type 1 Path 2 Resv 3 PathErr 4 ResvErr 5 PathTear 6 ResvTear 7 ResvConf 20 Hello 21 Notify Hardware signaling module 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. Hardware signaling module 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 module 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 module behavior: Save this field in a register, and use it to delimit the message 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 [6] to sup- November 6,

14 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> <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 mandatory 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 module behavior: Pass the message to the software signaling process if any objects other than the ones listed above are present 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 [6] 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> <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 November 6,

15 assigned to the LSP, is sent to the upstream LSR. There are 7 objects mandatory in Resv message, SESSION, RSVP_HOP, TIME_VALUES, STYLE, FLOWSPEC, FILTER_SPEC, and LABEL. The details of these objects will be given in Section 4.2. Hardware signaling module behavior: Pass the message to the software signaling process if any objects other than the ones listed above are present. We also limit the flow descriptor list to consist of only one descriptor, which consists of a FLOWSPEC, a FILTER_SPEC and a LABEL. In general, the flow descriptor list can have multiple flow descriptors. Our reason for this limitation is described in Section 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 Section 4.2. Hardware signaling module behavior: Pass the message to the software signaling process if any object other than the ones listed above are present ResvTear Message ResvTear message was initially defined in [8], page 42. No further modifications have been made in RSVP-TE. <ResvTear Message> :: =<Common Header> <SESSION> <RSVP_HOP> <STYLE> <flow descriptor list> <flow descriptor list>::= <FLOWSPEC> <FILTER_SPEC> The details of these objects will be given in Section 4.2. Hardware signaling module behavior: Pass the message to the software signaling process if there is more than one flow descriptor in the flow descriptor list, or if any object other than the ones listed above are present. November 6,

16 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 (bytes) Class-Num C-Type (Object contents)... Length: 16 bits The total object length in bytes. Hardware signaling module behavior: Use this field to delimit the object. Class-Num: 8 bits Identifies the object class. Hardware signaling module 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 for the types of objects to be handled by the hardware signaling module for the 4 messages, and Sections for specific Class_Num values handled by the hardware signaling module. C-Type: 8 bits Object type, unique within Class-Num. Hardware signaling module 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 for the corresponding Class_Num FILTER_SPEC FILTER_SPEC object was initially defined in [8], Class-Num 10, C-Type 1-3. In [6], C-Types 7-8 were added in support of LSP tunnel. In our application, C-Type is 7, meaning IPv4 LSP tunnel. Hardware signaling module accepts this object Class-Num=10 if C-Type=7. Otherwise, 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 FLOWSPEC FLOWSPEC object was initially defined in [8], Class-Num 9, C-Type 1-2. In [4], a new C-Type was introduced to support SONET/SDH traffic parameters. The value for this C-Type is not determined yet. Hardware signaling module 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. November 6,

17 4.2.3 LABEL (Generalized) LABEL object was initially defined in [6] 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 generalized LABEL for SONET/SDH. Hardware signaling module accepts this object Class-Num=16 if C-Type=2. Otherwise, it passes the message to the software signaling process. The Generalized Label object, carried in Resv message, extends the traditional label by allowing the representation of not only labels which travel in-band with associated data packets, but also labels which identify timeslots, wavelengths, or space division multiplexed position. In our application, SONET, a label represents a set of timeslots. Length Class-Num(16) C-Type(2) Label... Each Generalized Label object carries a variable length label. The format of the label depends on the application. Figure 6 shows the format of a SONET/SHD label. S U K L M FIGURE 6. Format of a SONET/SDH label U and K fields are used for SDH only and hence not checked by this hardware signaling module because our target switch is a SONET switch as specified in Section 3.3. S: 16 bits (1->N) Indicates a specific STS-1 inside an STS-N multiplex, only significant for STS-N(N>1) S SONET 0 OTHER 1 1st STS-1 2 2nd STS-1 3 3rd STS-1 4 4th STS N Nth STS-1 L: 4 bits (1->7) Indicates a specific VT Group within an STS-1 SPE. L SONET STS-1 SPE 0 OTHER 1 1st VTG 2 2nd VTG 3 3rd VTG November 6,

18 L SONET STS-1 SPE 4 4th VTG 5 5th VTG 6 6th VTG 7 7th VTG M: 4 bits Indicates a specific VT1.5 SPE, VT2 SPE or VT3 SPE with a VT Group. 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 Figure 7 shows the association of a Generalized Label to the SONET multiplexing hierarchy. The granularity can be as fine as 1.544Mbps (DS1). STS-3N xn S L M STS-3 SPE 3c x3 STS-1 SPE x7 For example, S>0, U=0, K=0, L=0, M=0 Denotes the unstructured SPE of the s-th STS-1. It is the case of our application. VT Group Hardware signaling module 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. It means L and M fields are of no significance. The possible value of S ranges from 1 to 12. 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 x2 x3 x4 VT-6 VT-3 VT-2 VT Mb Mb DS Mb DS Mb DS1C 2.048Mb E Mb DS1 FIGURE 7. SONET multiplexing hierarchy and generalized label November 6,

19 allocated label (for input interface) when processing the Label object in a Resv message LABEL_REQUEST (Generalized) LABEL_REQUEST object was initially defined in [6] to support the setup of an LSP tunnel, Class-Num 19, C-Type 1-3. In [3][4], a generalized LABEL_REQUEST object was introduced, suggested C-Type 4. Hardware signaling module accepts this object Class-Num=19 if C-Type=4. Otherwise, it passes the message to the software signaling process. The Generalized Label Request object defines the characteristics of the requested LSP. The software signaling process will download the appropriate values for the parameters of this object based on the type of switch served by the signaling engine. Length Class-Num(19) C-Type(4)[TBA] LSP Enc. Type Switching Type G-PID LSP Encoding Type: 8 bits Indicates the encoding of the LSP being requested. Value Type 1 Packet 2 Ethernet 3 ANSI/ETSI PDH 4 Reserved 5 SDH ITU-T G.707/SONET ANSI T Reserved 7 Digital Wrapper 8 Lambda (photonic) 9 Fiber 10 Reserved 11 FiberChannel Hardware signaling module 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. Value Type 1 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) November 6,

20 Value Type 150 Lambda-Switch Capable (LSC) 200 Fiber-Switch Capable (FSC) Hardware signaling module 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 module 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 RSVP_HOP RSVP_HOP object was initially defined in [8], Class-Num 3, C-Type 1-2. In [4], in order to support out-of-band signaling (separation of control channel and data channel), a new C-Type, with support for interface ID, was added. The suggested C-Type value is 3. Hardware signaling module accepts this object Class-Num=3 if C-Type=3. Otherwise, it passes the message to the software signaling process. In RSVP, RSVP_HOP object carries the IP address of the RSVP-capable node that sent this message, it is called PHOP ( previous hop ) in downstream messages (Path message) 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 channel, a IF_INDEX TLV is added. Length Class-Num(3) C-Type(3) TBA IPv4 Next/Previous Hop Address Logical Interface Handle TLVs... Hardware signaling module behavior: Pass the message to the software signaling process if there is more than one TLV. IPv4 Next/Previous Hop Address: 32 bits IP address of the previous LSR (Path message) or next LSR (Resv message), on the control plane. Hardware signaling module 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 during 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 November 6,

21 table. For messages originating from this transit switch, we use the same LIH (some constant value). IF_ID TLV: Type Value Length Length: 16 bits Indicates the total length of the TLV. Type: 16 bits Indicates type of interface being identified. Type Length Format Description 1 8 IPv4 Addr. IPv IPv6 Addr. IPv See below IF_INDEX (Interface Index) 4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface) 5 12 See below COMPONENT_IF_UPSTREAM (Component interface) Hardware signaling module 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: IP Address Interface ID 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 module 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. November 6,

22 Hardware signaling module behavior: Save this field in a register and the State table. This interface ID, together with IP Address, will be used to match the Connectivity 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 module 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 hardware signaling module only handles calls in which the required bandwidth is available 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 interfaces, then the message is passed on to the software signaling process SENDER_TEMPLATE SENDER_TEMPLATE object was initially defined in [8], Class-Num 11, C-Type 1-3. [6] introduced two new C-Types 7-8 to support LSP tunnel. In our application, C-Type 7 means an IPv4 LSP tunnel. Hardware signaling module accepts this object Class-Num=11 if C-Type=7. Otherwise, it passes the message to the software signaling process. The SENDER_TEMPLATE/FILTER_SPEC object specifies the source address of an LSP. SENDER_TEMPLATE object is carried in Path message, while the FILTER_SPEC object carried in Resv message. SENDER_TEMPLATE, together with SESSION object, uniquely identifies an LSP. Length Class-Num(11) C-Type(7) IPv4 tunnel sender address MUST be zero LSP ID IPv4 tunnel sender address: 32 bits IP address of the sender Hardware signaling module behavior: Save this field in a register and the State table. IP address of the sender (source IP address) will be used to match a row in the State table. LSP ID: 16 bits Locally (at the sender) allocated ID for the LSP Hardware signaling module behavior: Save this field in a register and the State table. It will be used to match a row in the State table SENDER_TSPEC SENDER_TSPEC object was initially defined in [8], Class-Num 12, C-Type 2. Reference [4] added a new C-Type to support SONET/SDH traffic parameters. The value for this C-Type is not determined yet. November 6,

23 Hardware signaling module 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/ SDH introduced a new C-Type (TBA). Length Class-Num(12) C-Type TBA Signal Type RCC NCC NVC Multiplier (MT) Transparency (T) Signal Type (ST): 8 bits Indicates the type of Elementary Signal that comprises the requested LSP. Value Type (Elementary Signal) 1 VT1.5 SPE / VC-11 2 VT2 SPE / VC-12 3 VT3 SPE 4 VT6 SPE / VC-2 5 STS-1 SPE / VC-3 6 STS-3c SPE / VC-4 7 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) Hardware signaling module behavior: The VSC9182 supports three crossconnect rates: STS-1, STS-3c, and STS-12c. The hardware signaling module 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 Signal. Only the first two bits of this field have been defined so far. Flag 1 (bit 1) Flag 2 (bit 2) Standard contiguous concatenation Arbitrary contiguous concatenation Hardware signaling module behavior: VSC9182 can only support standard contiguous 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 module behavior: See the MT description. November 6,

24 Number of Virtual Components (NVC): 16 bits Indicates the number of signals that are requested to be virtually concatenated. Hardware signaling module behavior: VSC9182 does not support virtual concatenation; 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 module 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 multiple interfaces. Given our statement in Section 3.3 that the hardware signaling module 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 specifies which fields in the SOH and LOH should be passed through from the ingress Flag 1 (bit 1) Flag 2 (bit 2) Flag 3 (bit 3) Flag 4 (bit 4) Flag 5 (bit 5) Flag 6 (bit 6) Flag 7 (bit 7) Flag 8 (bit 8) Flag 9 (bit 9) Flag 10 (bit 10) Flag 11 (bit 11) Section layer Line layer J0 SOH DCC (D1-D3) LOH DCC (D4-D12) LOH Extended DCC (D13-D156) K1/K2 E1 F1 E2 B1 switch to the egress switch of an LSP unmodified [6]. Hardware signaling module behavior: Save this field in a register and use it to program the switch chip so that the switch can pass on values received in the corresponding header fields unchanged. November 6,