Basic Features of GMPLS

226 WAVELENGTH ROUTING OPTICAL NETWORKS 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Reserved S Link flags Figure 9.22 Required information in the protection information. information also indicates whether the LSP is a primary or a secondary LSP. It is assumed that the protection capabilities of each link are known through the routing advertisements. The required information in the protection information is shown in Figure 9.22. The following fields have been defined: • Secondary S : A 1-bit field that is used to indicate that the requested LSP is a sec- ondary LSP. • Reserved : A 25-bit reserved field, set to 0. • Link flags : This field indicates the desired protection type on a link. The following flags have been defined: ◦ Enhanced: Indicates that a more reliable protection scheme than dedicated 1 + 1 should be used i.e., 4-fiber BLSR. ◦ Dedicated 1 + 1 : Indicates that a 1 + 1 protection scheme should be used. ◦ Dedicated 1:1: Indicates that a 1:1 protection scheme should be used. ◦ Shared: It indicates that a shared protection scheme 1:N should be used. ◦ Unprotected: No protection is required. ◦ Extra traffic: Indicates that the requested LSP should use links that are protecting other primary LSPs. The requested LSP can be pre-empted if the links carrying the primary LSPs fail. CR-LDP and RSVP-TE extensions for GMPLS GMPLS is an architecture, and as in the case of MPLS, it requires a signaling protocol for the reliable distribution of label bindings. Both CR-LDP and RSVP-TE have been extended to support GMPLS. IS-IS and OSPF have also been extended to support GMPLS. In the following section, we present the CR-LDP extensions for GMPLS; the RSVP-TE extensions for GMPLS are presented in Section 9.5.3.

9.5.2 CR-LDP Extensions for GMPLS

New TLVs have been introduced in CR-LDP to support the generalized label operation. Specifically, the generalized label request TLV is shown in Figure 9.23, the generalized 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 LSP enc. type G-PID Switching type Type Length U F Figure 9.23 The CR-LDP generalized label request TLV. GENERALIZED MPLS GMPLS 227 Type Length F Label 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 U Figure 9.24 The CR-LDP generalized label TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Action Label type Reserved Sub-channel 1 Sub-channel N … Type Length U F Figure 9.25 The CR-LDP label set TLV. Label request message Time B A E C D Label mapping message Figure 9.26 The establishment of a CR-LDP. label TLV is shown in Figure 9.24, the suggested label TLV is the same as the generalized label TLV, and the label set TLV is shown in Figure 9.25. The process of establishing a bidirectional LSP is the same as the one used to establish a unidirectional LSP with some additions. A unidirectional LSP, from LSR A to LSR E, is set up. This is done by using a label request message in the downstream direction from LSR A to LSR E, and a label mapping message in the upstream direction from LSR E to LSR A. See Figure 9.26; see also Section 7.2.1. Labels for the unidirectional LSP from LSR A to LSR E are set up as the label mapping message travels upstream. This is because an CR-LSP is set up using downstream on demand with ordered control. To support a bidirectional LSP an upstream label is added to the label request message. 228 WAVELENGTH ROUTING OPTICAL NETWORKS A receiving node provides a new upstream label and then forwards the request message to the next downstream node. In this way, as the request message propagates towards the destination LSR E, labels for the LSR E – LSR A path are being set up. The labels for the LSR A – LSR E path are set up as the mapping message propagates towards LSR A.

9.5.3 RSVP-TE Extensions For GMPLS

As in the case of CR-LDP, new objects have been introduced in RSVP-TE to support the generalized label operation. The generalized label request object and the suggested label object which are the same are shown in Figure 9.27; the generalized label object is shown in Figure 9.28; and the label set object is shown in Figure 9.29. Bidirectional LSPs are set up using the same process of establishing a unidirectional LSP with some additions. An upstream label is added to the Path message, which permits the allocation of labels along the path from the destination LSR to the source LSR. Labels along the path from the destination LSR to the source LSR are allocated as in the unidirectional LSP using the Resv message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 LSP enc. type G-PID Switching type Length Class-Num C-type Figure 9.27 The RSVP-TE generalized label request object. Label Length Class-Num C-type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Figure 9.28 The RSVP-TE generalized label object. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Action Label type Reserved Sub-channel 1 Sub-channel N … Length Class-Num C-type Figure 9.29 The RSVP-TE label set object. THE OIF UNI 229

9.6 THE OIF UNI

The OIF UNI specifies signaling procedures for clients to automatically create a connec- tion, delete a connection, and query the status of a connection over a wavelength routing network. The UNI signaling has been implemented by extending the label distribution protocols LDP and RSVP see Chapter 7. It also uses extensions of the Link Manage- ment Protocol LMP . The client is a packet-switching equipment, such as an IP router and an ATM switch, or a SONETSDH cross connect which is connected to the optical network. The client side of the OIF UNI is known as the UNI-C and the optical network side is known as the UNI-N. A SONETSDH link is used for the transmission of data between a client and its ingress optical node, known as the Terminal Network Element TNE. The transmission rate of the SONETSDH link can be up to STS-768STM-256. The UNI signaling messages between the UNI-C and the UNI-N are transported in IP packets, over the IP Control Channel IPCC. This channel can be in-fiber or out-of- fiber . The in-fiber IPCC is carried over a channel that is imbedded in the SONETSDH link used for the transmission of data. This channel is the line and section overhead D bytes see Section 2.3.2. The out-of-fiber channel is separate from the SONETSDH data link, and can be an Ethernet link between the UNI-C and UNI-N or an IP network see Figure 9.30. As mentioned above in Section 9.4, the UNI isolates the clients from the optical net- work. In view of this, the topology, resources, and addressing of the optical network is not revealed to the clients. The optical network can use internal addresses for internal routing, provisioning, and network management. These addresses are not revealed to the network clients, and are not within the scope of the OIF standardization process. In addition, the clients can use their own addresses. In view of this two sets of addresses, a Transport Network Administrative TNA address is used by the UNI to identify the address of a client. The TNA address is a globally uniquely defined address; it is distinct from the native address space of both the clients and the network. To maintain compatibility with network devices that use different addressing types, the TNA can be in the form of IPv4, IPv6, and NSAP see Section 5.5. The UNI allows a connection between two different TNA type addresses. The primary services offered to a client by the UNI is the ability to create and delete connections over the optical network on demand. In addition, neighbor and service dis- covery can be offered optionally. The neighbor discovery procedures allow a TNE and a directly attached client device to determine and identify each other, thus by-passing the necessary manual configuration of the corresponding UNI-C and UNI-N. Service discov- ery is a process by which a client device obtains information about available services from the optical network. UNI-C Client UNI-N TNE Data link IP network Figure 9.30 The out-of–fiber IPCC. 230 WAVELENGTH ROUTING OPTICAL NETWORKS

9.6.1 The UNI Abstract Messages

OIF has defined a number of abstract messages to be used over the UNI. The actual imple- mentation of these messages depends on whether LDP or RSVP is used. These messages are used to create a connection, delete a connection, and query the status of a connection established over the UNI. Recall that a connection is a lightpath or a subrate channel of a lightpath. From the UNI point of view, a connection is a fixed-size bandwidth circuit between an ingress and an egress optical node with a specified frame. At this moment, only SONETSDH framing is used. A connection can be unidirectional or bidirectional. The following abstract messages have been defined: • Connection create request : Sent by the source UNI-C to its ingress UNI-N to request the establishment of a connection. It is also sent from the destination egress UNI-N to the destination UNI-C to indicate an incoming connection request. • Connection create response : Used to inform the source UNI-C i.e. that initiated the connection request of the establishment of the connection. It is sent from the destination UNI-C to the destination UNI-N, and from the source UNI-N to the source UNI-C, which can then start transmitting data upon receipt of this message. • Connection create confirmation : Used from the source UNI-C to the source UNI-N to acknowledge completion of the connection establishment. It is also used by the destination UNI-N to the destination UNI-C to indicate that the connection has been successfully established. • Connection delete request : Used to initiate the deletion of a connection; it can be sent by either UNI-C. It can also be sent by the network in case of internal failure. • Connection delete response : Used to signal the completion of the deletion of a connec- tion procedure. • Connection status enquiry : This message is used to enquire about the status and attributes of a connection. • Connection status response : Used to return the status of the specified connection and its attributes. • Notification : Used by a UNI-N to either UNI-C to indicate a change of status of the connection. Figure 9.31 shows the messages involved in the establishment of a connection. As can be seen, the source UNI-C sends a connection establishment request to its ingress UNI-N. This request is propagated to the destination egress UNI-N, which it sends to the destina- tion UNI-C. A connection create response accepting the request is sent by the destination UNI-C to its UNI-N. This message is then propagated back to the source UNI-N, which it sends to the source UNI-C. Connection confirmation follows see Figure 9.31. Each message has a number of mandatory and optional attributes. These attributes are organized into the following logical categories: • Identification-related attributes : These include: the source and destination TNA addresses; the client or TNA port number used for the connection; a generalized label; and a local connection ID that are used in all messages to identify which connection they apply to. The local connection ID is assigned by the source UNI-C and, as its name implies, has local significance. That is, it is only valid between the UNI-C and the ingress UNI-N. A similar connection ID is used between the destination UNI-N and UNI-C. THE OIF UNI 231 Source UNI-C Source UNI-N Destination UNI-C Destination UNI-N Connection create response Connection create request Connection create request Connection create response Connection create confirm Connection create confirm Figure 9.31 Successful connection establishment. • Service-related attributes : These are: the encoding type; SONETSDH traffic parame- ters; directionality; a generalized payload identifier; and the service level. The encoding type indicates whether the format is SONET or SDH. The SONETSDH traffic param- eters provide information regarding the signal type and the way in which the data has been concatenated. The directionality attribute indicates whether the connection is unidirectional or bidirectional. The generalized payload identifier indicates the payload carried within the established connection. Finally, the service level attribute indicates a class of service. A carrier can specify a range of different classes of service, such as gold, bronze, and silver. Since the optical network is a circuit-switching network, these classes of service are not related to the familiar QoS parameters in packet-switching networks, such as packet loss and end-to-end delay. Rather, they refer to issues such as the required restoration scheme i.e., no restoration, 1 + 1 protection, etc. and the connection setup and hold priorities. • Routing-related attributes : The only attribute defined is diversity. This attribute can be used when a new connection is being created, to indicate the diversity of the new connection with a list of n existing connections that start at the same UNI-C. The attribute contains n items of the form diversity type, local connection ID, where the local connection ID indicates one of the n existing connections that start at the same UNI-C. The following diversity types are possible: ◦ Node diverse: The new connection shall not use any network nodes that are in the path of the connection denoted by the local connection ID. ◦ Link diverse: The new connection shall not use any network links that are in the path of the connection denoted by the local connection ID. ◦ Shared risk link group SRLG diverse: The new connection shall not use any network links that have the same SRLG as those in the path of the connection denoted by the local connection ID. ◦ Shared path: The new connection shall use the same network links as those used by the connection denoted by the local connection ID. • Policy-related attributes : The only attribute defined is the contract ID, which is assigned by the service provider and configured in the clients.