7.6. P-NNI Signaling Adaptations for Optical Networks

The P-NNI hierarchy, addressing, and peer group identification were discussed in Chapter 5. In the following, we look at P-NNI signaling features and their adaptation for signaling in optical networks. The peer group hierarchy depicted in Figure 5-15 is useful for the discussion below and hence it is reproduced as Figure 7-38.

7.6.1. P-NNI Signaling Communication

The signaling communication protocol model under P-NNI is shown in Figure 7-39. Here, the P-NNI protocol entities in peer nodes utilize a signaling ATM adaptation layer (SAAL) which consists of the following:

• A Service Specific Coordination Function (SSCF) specified in ITU-T recommendation Q.2130. This function maps the services of the lower layer, the Service Specific Connection Oriented Protocol (SSCOP), to the requirements of the P-NNI signaling procedures.

• SSCOP, which is specified in ITU-T recommendation Q.2110. This protocol provides a reliable delivery service between two (SSCOP) peer entities.

• The ATM Adaptation Layer Type 5 (AAL-5) functions as specified in ITU-T recommendation I.363. This function provides segmentation and reassembly of signaling protocol data units.

In short, P-NNI signaling utilizes a reliable transport protocol between signaling peers, over a physical or logical link. This is in contrast to RSVP-TE reliable messaging, which uses an underlying unreliable messaging procedure with protocol additions for reliability.

7.6.2. The Designated Transit List

The Designated Transit List (DTL) is the equivalent of the ERO in RSVP-TE (see section 7.4.2.1). The DTL indicates the route for a connection being provisioned within a single peer group. A sequence of DTLs are used to indicate the end-to-end route. The DTL is encoded as a list of nodes and (optionally) links to be visited, physical or logical, with a pointer indicating the next entity in the route. The contents of the DTL information element are indicated in Figure 7-40a. Here, the Current Transit Pointer field indicates the beginning of the next element to be processed in the list. The port identifier is set to 0 if only a node identifier is specified as the next element.

Figure 7-40b shows the complete sequence of DTLs for a connection being provisioned from node 1 to node 23 in Figure 7-38 (also see Figure 5-16). When processing the connection setup, the sequence of DTLs is treated as a stack, the topmost DTL in the stack indicating the route in the first level peer group, the next DTL below that indicating the route in the second-level peer group, and so on. In this example, the DTLs consist only of logical nodes (port identifier set to 0).

7.6.3. Connection Establishment and Deletion

Connection establishment is triggered by either management action or a request received over the UNI. This is similar to the manner in which provisioning triggers are received under RSVP-TE. Once the trigger is received, the ingress node computes a route to the destination and initiates P-NNI signaling to establish the connection. This is also similar to the RSVP-TE connection provisioning case described earlier. To look at more details, we can use the network shown in Figure 7-38. Suppose a connection is to be provisioned from node 1 to node 23. The provisioning request contains the connection attributes. Node 1 then computes a route for the connection and constructs a sequence of DTLs. This sequence was illustrated in Figure 7-40b. The node initiates signaling by sending a SETUP message to the next node (2) in the route. This message contains the connection parameters and the DTL. Node 2, after processing the message, returns a CALL PROCEEDING message to 1. This message, among other things, contains the ATM VPI/VCI values for the connection. This is similar to label assignment under RSVP-TE, except that the assignment happens hop by hop as the SETUP message proceeds rather than in a separate reverse phase as in RSVP-TE. The assigned VPI/VCI value can be used for both directions of the connection in case of a bidirectional connection. The SETUP message then proceeds to the next node, as shown in Figure 7-41. The interesting thing to note is that the DTL shown in Figure 7-40b ends with node 2 in peer group A.1, and continues with logical node A.2. Node 2 is able to send a SETUP message to node 8 in A.2, since it is directly connected to this node. The DTL sent in the SETUP message would start with A.2 and carry the rest of the DTLs shown in Figure 7-40b. Node 8 becomes responsible for expanding the DTL to include node 6 on the way to the next DTL element in the peer group, that is, A.3. Thus, the DTL gets expanded when the SETUP message hits a border node that has more information about the internals of a peer group whose logical identifier is included in the DTL. The SETUP message ultimately reaches node 23. The final route for this message is <1, 2, 8, 6, 9, 10, 12, 14, 18, 17, 22, 23>.

When the SETUP message has been accepted by node 23, it sends a CONNECT message to its predecessor (node 22). The CONNECT progresses in the reverse direction as the SETUP. A node receiving a CONNECT message sends a CONNECT ACK, as shown in Figure 7-41. When Node 1 receives the CONNECT message, the connection establishment is complete and data transmission can begin.

As in the RSVP-TE case, connection state is created in intermediate nodes when SETUP and CONNECT messages are processed. The details of this are not absolutely necessary for subsequent discussion, but we note that the state created is hard, that is, it is not deleted until the connection is de leted (either due to network action or from the end point). This is in contrast to RSVP-TE soft state.

Finally, a long list of ATM-specific connection attributes is carried in the SETUP and the CONNECT messages. The interested reader can refer to [ATMF02] for details.

The message sequence for the deletion of the connection that was set up in the last example is shown in Figure 7-42. The deletion is triggered by node 1, which sends a RELEASE message to the next node (2). This message identifies the connection to be deleted. After receiving the message, node 2 responds with a RELEASE COMPLETE message. The receipt of this message causes the connection state to be cleared in node 1. The same action is repeated along the connection path until the destination, node 23, receives the RELEASE and responds to it. More details on the contents of these messages, as well as details of other signaling messages defined under P-NNI can be found in [ATMF02].

7.6.4. P-NNI Adaptations for Signaling in Optical Networks

The changes to P-NNI required for signaling in optical networks consist of new information elements in signaling messages and insulation between the control and data planes. These are summarized below:

• Connection identification: As described in section 7.6.3, ATM VPI/VCI values are used during connection establishment as labels (this information is carried in the connection identifier information element). This must be substituted with the generalized label information pertaining to optical networking (e.g., a time slot, lambda, or port number).

• Traffic descriptors: P-NNI signaling messages carry ATM-specific traffic description parameters (similar to RSVP Sender Tspec). These must be replaced by optical network related connection parameters, such as the SONET/SDH parameters described in section 7.3.3.

• Separation of control and data planes: P-NNI signaling would release the connection if there is a disruption in the signaling path. What is required in optical networks, however, is the ability to keep data connections up if failures occur only in the control plane. This is the same issue with RSVP-TE, as described in section 7.5.

• Graceful deletion: Note that the P-NNI signaling deletion sequence shown in Figure 7-42 is similar to the RSVP-TE sequence where the source sends a deletion message that results in the removal of connection state at each hop. In optical networks, connection deletion in this manner may result in protection actions in downstream nodes. GMPLS RSVP-TE used extra phases in deletion-related signaling, utilizing the administrative status object (see Figure 7-37). A similar extension to signaling is needed with P-NNI.

On the plus side, P-NNI already supports certain procedures that are useful in connection-oriented networks. These include hard state and the ability to try alternate paths during signaling when the specified explicit route (DTL) is found to be infeasible.