Detailed description of GMPLS RSVP-TE signaling procedures for hardware implementation

Transcription

1 Detailed description of GMPLS RSVP-TE signaling procedures for hardware implementation Version 0, Revision 1 December, 2002 Haobo Wang, Malathi Veeraraghavan, Ramesh Karri Polytechnic University haobo_w@photon.poly.edu, mv@poly.edu, ramesh@india.poly.edu December 30,

2 Abbreviations and Acronyms ATM Asynchronous Transfer Mode CAC Connection Admission Control CR-LDP Constraint-based Routing-LDP FPGA Field Programmable Gate Array GMPLS Generalized MPLS LDP Label Distribution Protocol LMP Link Management Protocol LSP Label Switched Path LSR Label Switched Router MPLS MultiProtocol Label Switching OC Optical Carrier OCSP Optical Circuit-switched Signaling Protocol OSPF Open Shortest Path First OSPF-TE OSPF-Traffic Engineering 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 VCC Virtual Channel Connection VPC Virtual Path Connection December 30,

3 1. Introduction 1 This document is a detailed design document for an FPGA implementation of the RSVP subset defined in [1]. Four messages are processed in the hardware signaling module, 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 module. Some numbers are hardwired into the implementation instead of being set in initialization 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 processor compare the message type value carried in an incoming message with these allowedmessage-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 had to 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 in [1]. For example, the separation of control plane and user plane, allowing 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 module 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 messages. 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 interfaces and operates at a crossconnect rate of OC1. Of all the functionality specified as being supported in [1], the only change we made is to not support bandwidth negotiation in the hardware implementation. Thus, the hardware signaling module 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 signaling message to the software signaling process for handling. We found this negotiation process to be too complex for immediate hardware implementation. 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. December 30,

4 Figure 1 shows the prefixes and suffixes we used in this document. FIGURE 1. Prefixes and suffixes used in this document December 30,

5 2. Registers TABLE 1. Registers extracted from messages Register Width (bit) Description Msg_Type 8 Message type, Msg Type in Common Header Msg_Len 16 Message length, RSVP length in Common Header Local_Chksum 16 Locally calculated checksum Send_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 SES- SION object within Path/Resv message Tunnel_ID 16 Tunnel ID in SESSION object within Path/Resv message Ext_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 Data/Control Mapping table lookup LIH 32 Logical Interface Handle in RSVP_HOP object within Path message 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 message Tmp_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 lookup Seq_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 ID Outgoing_PHY_ID 8 Outgoing physical interface ID Incoming_Assigned_T 12 Timeslots assigned to a certain incoming logical link imeslots Outgoing_Assigned_T imeslots 12 Timeslots assigned to a certain outgoing logical link December 30,

6 Register TABLE 1. Registers extracted from messages Width (bit) Description Incoming_Label(s) 32 Generalized label(s) for the incoming interface, locally allocated Outgoing_Label(s) 32 Generalized label(s) for the outgoing interface, received from downstream LSR 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 message State 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 message G-PID 16 Generalized PID in LABEL_REQUEST object within Path message Refresh_Period 32 Refresh Period in TIME_VALUES object within Path message Style 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.105 Initialized_Switching_Type Time-Division-Multiplex Capable (TDM) Local_IP_Addr_User 32 - Local IP address on the user plane Local_IP_Addr_Ctrl 32 - Local IP address on the control plane Supported_ST 8 1 The crossconnect rate of the switch - 1 means OC1 December 30,

7 3. Data tables Figure 2 is an illustrative network that shows the possibilities accommodated in our signaling engine. Figure 3 shows the signaling message flow while setting up a circuit.it shows the upstream-downstream relation between switches on the path of a connection. Network of IP routers (not necessarily the Internet; could be a specially designed IP network just for signaling traffic) Signaling engine Client Server Signaling engine Switch Signaling engine Signaling engine Serverto-client SONET unidirectional circuit Logical link Switch I Switch II Switch III Physical interface: 5 Physical interface: 5 Physical Physical interface: 7 interface: 2 FIGURE 2. Network used for illustrative examples; shows that (i) switches can be connected via many user-plane interfaces (ii) logical links can be provisioned between non-adjacent switches (iii) a signaling engine may have many signaling links leading to the connectionless signaling network (IP network) Switch SW 4 Switch SW 5 5.Resv 8.Resv 6.Resv End Switch 7.Resv Switch Switch End Device SW 1 SW 2 SW Device 3 1.Path 2.Path 3.Path 4.Path Upstream Downstream Upstream 9. Connection (circuit or virtual circuit) established Downstream FIGURE 3. Signaling message flow for setting up a unidirectional circuit; SW1 is upstream relative to SW2, and SW2 is upstream relative to SW3 because of the direction of the circuit; the data sender initiates circuit setup December 30,

8 3.1 Routing table TABLE 3. Routing table Index Dest_IP_Addr Return value Next_IP_Addr_User 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 module. 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 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 module 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. 3.2 Incoming Connectivity table TABLE 4. Incoming Connectivity table Index Pre_IP_Addr_User Pre_IF_ID_User Incoming_IF _ID_User Return value Incoming_PHY_ID Incoming_Assigned _Timeslots 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 module. It shows how the interface numbers used by a neighbor maps to an incoming interface number 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 Figure 2, 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 interface 5 are terminated at switch II while the remaining timeslots 4-12 (we assume all interfaces 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 logical interface number that maps to a physical interface and timeslots is used in signaling messages to identify logical links. TABLE 5. Incoming Connectivity table at switch II in Figure 2 Index Return value Pre_IP_Addr_User Pre_IF_ID_User Incoming_IF _ID_User Incoming_PHY_ID Incoming_Assigned _Timeslots Switch I IP address Switch I IP address December 30,

9 3.3 Incoming CAC table TABLE 6. Incoming CAC table Index Incoming_PHY_ID Return value Avail_BW The Incoming CAC table, Table 6, shows the available bandwidth for each physical interface. Using the example shown in Figure 2, the Incoming CAC table at switch II will have entries as shown in Table 7. TABLE 7. Incoming CAC table at switch II in Figure 2 Index Return value Incoming_PHY_ID Avail_BW 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. Figure 4 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 corresponding bits to : Available 0: Not available (reserved) FIGURE 4. Example of Avail_BW 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 sufficient 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. December 30,

10 3.4 Outgoing Connectivity table TABLE 8. Outgoing Connectivity table Index Return value Next_IP_Addr_User Seq_Num Outgoing_IF_ID _User Outgoing _PHY_ID Outgoing_ Assigned_T imeslots The Outgoing Connectivity table, Table 8, shows the outgoing interfaces leading to neighboring switches. It also maintains mapping of logical interface IDs to physical interface IDs and corresponding timeslots. Since a switch may have multiple links to a neighbor, 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 signaling module to search this table multiple times until it finds an interface to the neighboring switch with sufficient available resources or exhausts all interfaces to the neighboring switches. An example Outgoing Connectivity table is shown for switch I in Figure 2. Timeslots 1-3 on physical interface 5 at switch I terminate at switch II while the remaining are routed through as a logical link to Switch III. 3.5 Outgoing CAC table TABLE 9. Outgoing Connectivity table for switch I in Figure 2 Index Return value Next_IP_Addr_User Seq_Num Outgoing_I F_ID_User Outgoing _PHY_ID Outgoing_Assi gned_timeslots Switch II IP address Switch II IP address Switch III IP address TABLE 10. Outgoing CAC table Index Outgoing_PHY_ID Return value Avail_BW 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 Outgoing CAC table. TABLE 11. Outgoing CAC table for switch I in Figure 2 Index Return value Outgoing_PHY_ID Avail_BW December 30,

11 3.6 Data/Control Mapping table TABLE 12. Data/Control Mapping table Index Next_IP_Addr_User Return value Next_IP_Addr_Ctrl 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 channels from corresponding data links. The Data/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 Figure 2. A switch may also have multiple control plane interfaces as shown in Figure 2 for switch II. We assume that load balancing of signaling load across multiple control plane interfaces will be done outside the signaling module and appropriate data downloaded to this Data/Control Mapping table. We assume that there is only one Next_IP_Addr_Ctrl associated with each next-hop switch. 3.7 State table TABLE 13. State table Index (Global connection reference) Control plane Return value Data plane Src_ IP_ Addr LSP _ID Dest _IP_ Addr Tun nel_ ID Ext_ Tunn el_id Pre_IP _Addr _Ctrl LIH Next_I P_Add r_ctrl Pre_IP _Addr _User Pre_I F_ID _User Incomi ng_ass igned_ Timesl ots Outgoi ng_ass igned_ Timesl ots Return value (con t) Data plane (con t) Incoming _IF_ID_ User Incoming_ PHY_ID Incoming _Label(s) Next_I P_Add r_user Outgoing _IF_ID_ User Outgoing _PHY_I D Outgoing _Label(s) Traffic _Spec State 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 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 Figure 5. 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 determined and resources are reserved. The LSP then enters the RESERVED state. When the December 30,

12 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. FIGURE 5. State transition diagram December 30,

13 TABLE 14. An example state table entry at switch II for the connection shown in Figure 2 Src_ IP_ Addr Serv er s IP addr ess Index (Global connection reference) LSP _ID Dest _IP_ Addr 1 Client s IP addr ess Tun nel_ ID Ext_ Tunn el_id Pre_IP _Addr _Ctrl 1 1 Switch I s Control plane IP addres s Control plane LIH Next_I P_Add r_ctrl 1 Switch III s Control plane IP addres s Return value Pre_IP _Addr _User Switch I s userplane IP addres s Data plane Pre_I F_ID _User Incomi ng_ass igned_ Timesl ots Outgoi ng_ass igned_ Timesl ots Return value (con t) Data plane (con t) Incoming _IF_ID_ User Incoming_ PHY_ID Incoming _Label(s) Next_I P_Add r_user 1 5 Switch I s userplane IP addres s Outgoing _IF_ID_ User Outgoing _PHY_I D Outgoing _Label(s) Traffic _Spec OC1 2 An example entry is shown in Table 14 for the connection from the server to the clientshown in Figure 2 at switch II. We assume that the server-to-client connection shown in Figure 2 is routed on the logical link from 6-1 between switch I and switch II and then connected 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 (downstream) switch but a Resv message is not yet received. Therefore the incoming and outgoing labels are not yet assigned. State December 30,

14 4. Procedures When a message is parsed, fields from within objects are stored into registers. For field names consult the message specifications in [1]. 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 corresponding 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 available 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 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 separation of control-plane and user-plane interfaces, reference [5] 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 provide the detailed flow charts for processing the four signaling messages and their associated objects. We use the following notation: 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 [1], 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 [1]). We note that there is potential for a conflict to arise given the current GMPLS signaling 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 , out of a possible 12 timeslots on an OC12 interface. Say the first call requests an OC1; the upstream switch tentatively reserves the first December 30,

15 time slot. It sets the Avail_BW in the Outgoing CAC table for the corresponding physical interface to be (ignore the values in the last 8 bits). This update is shown in Figure 8. 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 reservation 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 networks. In GMPLS networks, where hard resource reservations of timeslots and wavelengths 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. December 30,

16 FIGURE 6. Processing of common header December 30,

17 FIGURE 7. Processing of Path message December 30,

18 FIGURE 8. SESSION and SENDER_TEMPLATE objects in Path message December 30,

19 FIGURE 9. Processing of RSVP_HOP object in Path message December 30,

20 FIGURE 10. Processing of TIME_VALUES object in any message FIGURE 11. Processing of SENDER_TSPEC object in Path message December 30,

21 FIGURE 12. Processing of LABEL_REQUEST object in Path message December 30,

22 FIGURE 13. At the end of Path message processing After processing all the objects in a Path message, the state table is updated by copying values from the registers shown in the right-hand column of table in the following manner: 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 TABLE 15. Updating State table after processing a Path message December 30,

23 Pre_IF_ID_User Incoming_IF_ID_User Incoming_PHY_ID Incoming_Label(s) Incoming_Assigned_Time slots Next_IP_Addr_User Outgoing_IF_ID_User Outgoing_PHY_ID Outgoing_Label(s) Outgoing_Assigned_Time slots Traffic_Spec Pre_IF_ID_User Incoming_IF_ID_User Incoming_PHY_ID NULL Incoming_Assigned_Time slots Next_IP_Addr_User Outgoing_IF_ID_User Outgoing_PHY_ID NULL Outgoing_Assigned_Time slots <Signal_Type, RCC, NCC, NVC, MT> TABLE 15. Updating State table after processing a Path message To create the outgoing Path message, the hardware signaling module should construct a message following the details of the object formats from [1]. 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 construct the RSVP_HOP object are shown in Figure 14. The destination IP address for the Path message should be obtained from the Next_IP_Addr_Ctrl register. FIGURE 14. Assemble new Path message December 30,

24 FIGURE 15. Processing of Resv message December 30,

25 FIGURE 16. Processing of SESSION and FILTER_SPEC objects in Resv message December 30,

26 G 1 i f S O i ** Extract from Page 39, RFC 2205: 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 [7]: A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs. December 30,

27 FIGURE 18. Processing of STYLE object in any message FIGURE 19. Processing of FLOWSPEC object in Resv message December 30,

28 FIGURE 20. Processing of LABEL object in Resv message December 30,

29 FIGURE 21. At the end of Resv message processing FIGURE 22. Assemble new Resv message December 30,

30 FIGURE 23. Processing of PathTear message 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. December 30,

31 FIGURE 24. Processing of SESSION and SENDER_TEMPLATE objects in PathTear message December 30,

32 FIGURE 25. At the end of PathTear message processing FIGURE 26. Assemble new PathTear message December 30,

33 FIGURE 27. Processing of ResvTear message December 30,

34 FIGURE 28. Processing of SESSION and FILTER_SPEC objects in ResvTear message December 30,

35 FIGURE 29. At the end of ResvTear message processing FIGURE 30. Assemble new ResvTear message References [1] H. Wang, M. Veeraraghavan, T. Li, Specification of a Subset of RSVP-TE for Hardware Implementation, Nov. 2002, [2] H.Wang, M.Veeraraghavan and R. Karri, A hardware implementation of a signaling protocol, accepted to Opticomm 2002, July 29-Aug. 2, 2002, Boston, MA. December 30,

36 [3] E. Mannie, GMPLS Architecture, IETF Internet Draft, draft-many-gmpls-architecture-00.txt, Mar [4] E. Mannie (editor) et al., GMPLS Extensions for SONET and SDH Control, IETF Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-01.txt, June [5] P. Ashwood-Smith, et al. Generalized MPLS - Signaling Functional Description, IETF Internet Draft draft-ietf-mpls-generalized-signaling-05.txt, July [6] P. Ashwood-Smith, et al, Generalized MPLS Signaling - CR-LDP Extensions, IETF Internet Draft, draft-ietf-mpls-generalized-cr-ldp-03.txt, May [7] P. Ashwood-Smith, et al. Generalized MPLS - RSVP-TE Extensions, IETF Internet Draft, draftietf-mpls-generalized-rsvp-te-08.txt, August December 30,

37 5. Appendix 5.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 [2], and clarify the definition of certain terms. Message Setup and Setup-success (OCSP); Path and Resv (RSVP) Release and Release- Confirm (OCSP); PathTear and ResvTear (RSVP) TABLE 16. Mapping parameters of OCSP to RSVP fields in objects Optical Circuit Signaling Protocol (OCSP) Connection reference Destination IP address Source IP address Previous node s IP address RSVP 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 IPv4 tunnel end point address within the SES- SION object IPv4 tunnel sender address within SENDER_TEMPLATE/FILTER_SPEC object 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 object TTL RECORD_ROUTE object is used for loop detection (like PATH_VECTOR in LDP). This is optional, which means it will be handled in software. 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 routing table used for IP forwarding is the same routing 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 during call setup. Checksum RSVP_Checksum No corresponding parameter TIME_VALUES object Cause Connection reference (Prev) Connection reference (own) No corresponding parameters No corresponding parameter 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 RSVP_HOP in both and STYLE, FLOWSPEC in ResvTear December 30,

38 5.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 references identify a connection globally across all switches. Usage of local connection references 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. 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 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 tunnel 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 A traffic trunk is an aggregation 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 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- December 30,

39 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 tunnel 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 specific 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. Therefore 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 choosing global connection references instead of local connection reference, attention was not paid to performance aspects. LSP1+LSP2 = TE tunnel end host or IP router LSP2 LSP1 Also, the reason for having both a tunnel ID and and an LSP ID is that there is no concept 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. 5.3 Explanation for Style If an end host asks for 7VT1.5 to carry an Ethernet signal, each VT1.5 could be carried on a separate path. All have the same tunnel ID, but different LSP IDs. LSP tunnel end host or IP router FIGURE 31. LSP tunnels, LSPs, TE tunnels 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 reservation (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 December 30,

40 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 running on this UDP port is generating multicast traffic with the SENDER_TSPEC characteristics. December 30,

41 List of Figures FIGURE 1. Prefixes and suffixes used in this document...4 FIGURE 2. Network used for illustrative examples; shows that (i) switches can be connected via many user-plane interfaces (ii) logical links can be provisioned between non-adjacent switches (iii) a signaling engine may have many signaling links leading to the connectionless signaling network (IP network)7 FIGURE 3. Signaling message flow for setting up a unidirectional circuit; SW1 is upstream relative to SW2, and SW2 is upstream relative to SW3 because of the direction of the circuit; the data sender initiates circuit setup7 FIGURE 4. Example of Avail_BW...9 FIGURE 5. State transition diagram...12 FIGURE 6. Processing of common header...16 FIGURE 7. Processing of Path message...17 FIGURE 8. SESSION and SENDER_TEMPLATE objects in Path message...18 FIGURE 9. Processing of RSVP_HOP object in Path message...19 FIGURE 10. Processing of TIME_VALUES object in any message...20 FIGURE 11. Processing of SENDER_TSPEC object in Path message...20 FIGURE 12. Processing of LABEL_REQUEST object in Path message...21 FIGURE 13. At the end of Path message processing...22 FIGURE 14. Assemble new Path message...23 FIGURE 15. Processing of Resv message...24 FIGURE 16. Processing of SESSION and FILTER_SPEC objects in Resv message...25 FIGURE 17. Processing of RSVP_HOP in Resv message...26 FIGURE 18. Processing of STYLE object in any message...27 FIGURE 19. Processing of FLOWSPEC object in Resv message...27 FIGURE 20. Processing of LABEL object in Resv message...28 FIGURE 21. At the end of Resv message processing...29 FIGURE 22. Assemble new Resv message...29 FIGURE 23. Processing of PathTear message...30 FIGURE 24. Processing of SESSION and SENDER_TEMPLATE objects in PathTear message...31 FIGURE 25. At the end of PathTear message processing...32 FIGURE 26. Assemble new PathTear message...32 FIGURE 27. Processing of ResvTear message...33 FIGURE 28. Processing of SESSION and FILTER_SPEC objects in ResvTear message...34 FIGURE 29. At the end of ResvTear message processing...35 FIGURE 30. Assemble new ResvTear message...35 FIGURE 31. LSP tunnels, LSPs, TE tunnels...39 December 30,

42 List of Tables TABLE 1. Registers extracted from messages...5 TABLE 2. Initialization registers...6 TABLE 3. Routing table...8 TABLE 4. Incoming Connectivity table...8 TABLE 5. Incoming Connectivity table at switch II in Figure TABLE 6. Incoming CAC table...9 TABLE 7. Incoming CAC table at switch II in Figure TABLE 8. Outgoing Connectivity table...10 TABLE 9. Outgoing Connectivity table for switch I in Figure TABLE 10. Outgoing CAC table...10 TABLE 11. Outgoing CAC table for switch I in Figure TABLE 12. Data/Control Mapping table...11 TABLE 13. State table...11 TABLE 14. An example state table entry at switch II for the connection shown in Figure TABLE 15. Updating State table after processing a Path message...22 TABLE 16. Mapping parameters of OCSP to RSVP fields in objects...37 December 30,