NSIS Working Group Internet Draft Thanh Tra Luu Exprires : April 2004 Nadia Boukhatem ENST Paris G. Pujolle University of Paris 6 V. YILMAZ THALES Communications, LIP6 Y. EL Mghazli Alcatel October 2003 NSIS Transport Layer Protocol Considerations and Implementation draft-luu-ntlp-con-imp-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract: The working group NSIS (Next Step In Signaling) is created with the ambition to define a new signaling protocol. This signaling protocol will be generic and applicable to the most of present and future signaling applications. Some of these signaling applications are resource reservation, communication protocol for middlebox, VPN, etc. The intention of NSIS is to re-use, where appropriate, the protocol mechanisms of RSVP while at the same time simplifying it and applying a more general signaling model. NSIS signaling protocol is composed of two layers. NTLP (NSIS Transport Layer Protocol) layer is responsible for transporting Luu et al. [Page 1] NTLP considerations and implementation October 2003 signaling messages. NSLP (NSIS Signaling Layer Protocol) is the upper layer which contains functionality such as message formats and sequences, specific to a particular signaling application. This document outlines the proposal of implementation for NTLP which can satisfy the requirements defined in the NSIS working group. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [6] Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. NTLP : requirements and considerations . . . . . . . . . . . . 3 2.1. Soft-state management . . . . . . . . . . . . . . . . . . 3 2.2. Identification. . . . . . . . . . . . . . . . . . . . . . 3 2.3. Relationship between NTLP and underlying layer. . . . . . 5 3. NSIS Transport Layer Protocol. . . . . . . . . . . . . . . . 5 3.1. Common header. . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Object format . . . . . . . . . . . . . . . . . . . . . . 7 3.3. NTLP message. . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. New message. . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Mod message. . . . . . . . . . . . . . . . . . . . . . 12 3.3.2.1. Mod message in the direction of data path . . . . . 13 3.3.2.2. Mod message in the opposite direction of data path. . 14 3.3.3. INFO message . . . . . . . . . . . . . . . . . . . . . 15 3.4. NTLP objects. . . . . . . . . . . . . . . . . . . . . . . 18 3.4.1. INTEGRITY class. . . . . . . . . . . . . . . . . . . . . 18 3.4.2. IP_HOP class. . . . . . . . . . . . . . . . . . . . . . 19 3.4.3. TIME_VALUE class. . . . . . . . . . . . . . . . . . . . 20 3.4.4. FLOW_ID class. . . . . . . . . . . . . . . . . . . . . . 20 3.4.5. SESSION class. . . . . . . . . . . . . . . . . . . . . . 21 3.4.6. SESSION_ERROR class. . . . . . . . . . . . . . . . . . . 27 3.4.7. SESSION_FRAGMENT class. . . . . . . . . . . . . . . . . 27 3.4.8. NSLP_INFO class. . . . . . . . . . . . . . . . . . . . . 28 3.4.9. NTLP_INFO class. . . . . . . . . . . . . . . . . . . . . 28 4. NTLP and NSLP. . . . . . . . . . . . . . . . . . . . . . . . . .29 4.1. Using NTLP for resource reservation in IntServ environment.29 4.1.1. Receiver-initiated approach. . . . . . . . . . . . . . . 29 4.1.1.1. Path message . . . . . . . . . . . . . . . . . . . . . 30 4.1.1.2. Resv message. . . . . . . . . . . . . . . . . . . . . 32 4.1.1.3. Other messages. . . . . . . . . . . . . . . . . . . . .35 4.1.2. Sender-initiated approach. . . . . . . . . . . . . . . . 36 4.1.2.1. Path message. . . . . . . . . . . . . . . . . . . . . .36 Luu et al. [Page 2] NTLP considerations and implementation October 2003 4.1.2.2. ACK message. . . . . . . . . . . . . . . . . . . . . . 36 4.1.2.3. PathTear message. . . . . . . . . . . . . . . . . . . .36 4.1.2.4. Bi-directional reservation. . . . . . . . . . . . . . .37 4.2. NTLP for Middlebox configuration. . . . . . . . . . . . . .37 4.2.1. Path message. . . . . . . . . . . . . . . . . . . . . . .37 4.2.2. Create message. . . . . . . . . . . . . . . . . . . . . .39 4.2.3. Release message . . . . . . . . . . . . . . . . . . . . .39 4.2.4. Query. . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2.5. Response. . . . . . . . . . . . . . . . . . . . . . . . .39 4.2.6. Trigger message. . . . . . . . . . . . . . . . . . . . . 39 5. Security considerations. . . . . . . . . . . . . . . . . . . . 40 6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 40 Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .42 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .42 1. Introduction The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol. The signaling would be a new and generic signaling. The NSIS protocol suite is structured into two layers: -NTLP: NSIS Transport Layer Protocol is responsible for moving signaling messages around, which should be independent of any particular signaling application. -NSLP: NSIS Signaling Layer Protocol is the upper layer which contains functionality such as message formats and sequences, specific to a particular signaling application. In the split-layer protocol structure, a function of protocol has to be located in the lower layer (NTLP), the upper layer (NSLP) or in both layers. For example, the state management function can be located in NTLP. In this case, NTLP supports the refresh messages used for soft-state maintenance. The characteristics of these messages are that they can be sent and processed without invoking signaling application. Nevertheless, a state can be maintained by NSLP. In this case, a NSLP can refresh an established state by sending the same message as the one which was previously sent to establish the state. Making a decision which layer does a function is not easy. This decision must be generic for all signalling applications. As a result, the NSIS Group spent a lot of time to decide which layer is responsible for a function. In this document, we propose a protocol matching to the NTLP Luu et al. [Page 3] NTLP considerations and implementation October 2003 protocol. The NTLP protocol is implemented based on the requirements of [3] and the guidelines in the framework of NSIS [4] and the discussion in the NSIS working group. There is no new requirement which is defined in this documents. The separation of NSLP and NTLP becomes clearer by determining how functions (e.g. soft state management, fragmentation...) are implemented through NSLP and NTLP. This document is just an effort to synthesize the discussion in the working group and to develop it as a generic signaling protocol. This proposal of NTLP is rather different from [7] and [8]. However, it is designed with a great reference to [1][2][7]. The document is composed of three main sections. The first section presents some considerations for NTLP. This section presents a review of potential requirements of NTLP. The second section describes the format of the messages and the objects of NTLP. The last section is the discussion on how the protocol ensures the requirements of [3][4][5]. 2. NTLP : requirements and considerations In this section, we present our considerations about some crucial points of NTLP. 2.1. Soft-state management Soft-state means that after being established on an entity, a state will be deleted on that entity if it is not periodically refreshed during a specific period. Soft-state is used to avoid the faults and the cases that an explicit command to delete an established state can not be done (e.g. interruption of connection, a router on the path unexpectedly shuts down). The RSVP protocol [1][2] is an excellent example for soft-state. A state is established on a router when it receives a trigger message. This state is deleted if the router does not periodically receive a refresh message. However, this state can be explicitly deleted. NSIS signaling must support soft-state for signaling applications. It means that NSIS entity (NE) can send and receive refresh messages to keep an established state from being deleted. But this does not mean that all NE on the signaling path must support soft-state for a signaling application. In fact, to reduce the load on the intermediate nodes, some intermediate NEs are able to not establish state (stateless nodes) for a specific signaling application [9]. 2.2. Identification In [3][4], NSIS introduces three identifiers for a NSIS signaling as flow identifier, session identifier and NSLP identifier. Luu et al. [Page 4] NTLP considerations and implementation October 2003 Flow identifier (FLOW_ID) is used to identify a flow in a unique way. Information that could be used in FLOW_ID may include source IP address, destination IP address, protocol identifier, port, flow label (IPv6), SPI, DSCP/TOS field. The flow identification is an explicit part of NTLP and is not hidden within NSLP because in some NSLP-unaware point, the NTLP can also process this identifier. The function of FLOW_ID is to provide enough information such that the signaling flow gets the same treatment as the data flow. However, FLOW_ID can change within the same signaling session of an application (e.g. IP address can be changed due to a handover). That is why SESSION_ID is used to identify a signaling session. The session identifier (SESSION_ID) is essentially a signaling application concept, since it is only used in non-trivial state management actions that are application specific. SESSION_ID is visible within the NTLP. NTLP can use this identification to control its state and to demultiplex received signaling messages between multiple instances of the same signaling application. In fact, the session identifier provides a method to correlate the signaling about the different flows with the same network control state. SESSION_ID is a unique global identifier for a signaling application at a specific time. There are some proposals of how to create SESSION_ID like creating a random number (32 bits, 64 bits, 128 bits) or combining a random number with the IP source or destination address [7][8]. These proposals prove that the probability of collision is small enough to be considered. However, there is still a very small probability of collision. Moreover, from a security point of view, if a hacker eavesdrops the SESSION_ID of an user and creates the same SESSION_ID number, he can interfere or control the established session. Since the NTLP can support several NSLP signaling application, there is a need to identify which signaling application a particular message belongs to. As a result, NSLP identifier (NSLP_ID) is defined as a number to identifier a particular NSLP signaling application. NSLP identifier (NSLP_ID) is used by NTLP to demultiplex signaling messages towards the appropriate signaling applications. If a node does not handle the specific signaling application, NTLP should be able to make a forwarding decision without having to parse upper layer information. The NSLP_ID can be a part of the SESSION_ID. In a node, there can be a great number of SESSION_IDs. Therefore, using NSLP_ID is an effective way to classify the SESSION_ID. For instance, in the case the state is only established in NSLP-aware nodes, after checking NSLP_ID, if a node does not support a specific NSLP, it can immediately forward the message. Luu et al. [Page 5] NTLP considerations and implementation October 2003 2.3. Relationship between NTLP and underlying layer In NSIS framework, NTLP can run directly on the IP protocol or on some other transport protocols such as TCP/SCTP or UDP. It will be easier to create a signaling protocol without constraints using IP or UDP as an underlying layer. In this case, all functions of the signaling protocol must be designed and implemented within NTLP and NSLP. For example, the transport functions (e.g. overload control, reliable message delivery...) must be supported by NTLP or NSLP. If the signaling protocol uses underlying protocols with transport functions (e.g. TCP/SCTP), theses functions can be reused to support signaling applications rather than implement these functions within NTLP and NSLP. Much time and effort can be saved thanks to reusing these functions. However, in this case, all the functions are not always necessary for a signaling application. For example, reliable message delivery is not mandatory for some signaling messages. Moreover, signaling applications must bear all security attacks of these protocols (e.g. SYN TCP attack). 3. NSIS Transport Layer Protocol In this document, the NTLP is designed to run directly on the IP layer. However, it can run on transport protocols such as UDP or other protocols. The NTLP has its own transport functions such as fragmentation and reliable message delivery. The congestion/flow control is not specified in this document. It will be further supported by specifying NTLP_INFO and NSLP_INFO objects. In case a lower protocol can support these functions, these functions of NTLP can be used as optional functions. An NTLP message consists of a common header, followed by a body consisting of a variable number of variable-length objects. The following subsections define the formats of the common header, the standard object header, and each of the NTLP message types. For each NTLP message type, a set of rules for the permissible choice of Object types is defined. These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. 3.1. Common header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | M_Type| Flags | NTLP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send_TTL | Reserved | NTLP Length | Luu et al. [Page 6] NTLP considerations and implementation October 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the common header are as follows: Vers: 4 bits NTLP protocol version number. This is version 1. M_Type : Message Type 4 bit : M_Type = 1 : Message type is New M_Type = 2 : Message type is Mod M_Type = 3 : Message type is Info Flag : 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | SM | (Resv) | +-+-+-+-+-+-+-+-+ SM: State management 3 bits: SM=0: when an intermediate NSIS-aware node receives this message, it MUST not entirely examine the message. It SHOULD check the Integrity object to assure the hop by hop security. The message is forwarded without establishing state. SM=0 can be used for directly sending a signaling message between two NEs without interference of intermediate nodes except assuring the hop by hop security. SM=1: when an intermediate NTLP node receives this message, NTLP MUST entirely examine the message. If the state is not yet established, it must establish a state for this new session. SM=1 can be used for the signaling applications which need to establish a state on all NTLP-aware nodes on the signalling path. SM=2: If an intermediate node that supports a specific NSLP receives this message, NTLP MUST entirely examine the message. If the state is not yet established, it must establish the state of this new session. SM=2 can be used for signalling applications that only need to establish state on Luu et al. [Page 7] NTLP considerations and implementation October 2003 the NSLP-aware nodes. SM=3: If an intermediate node of a specific NSLP-aware receives this message, NTLP MUST entirely examine the message. If the state is not yet established, NTLP MUST wait the decision of NSLP to know whether the state must be established. If the node is not a specific NSLP-aware, NTLP MUST not examine the entire message. It can check the Integrity object to assure the hop by hop security. (Resv): 5 last bits of flag are reserved for the future use. NTLP Checksum: 16 bits The one's complement of the one's complement sum of the message, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. Send_TTL: 8 bits The IP TTL value with which the message was sent. This is used to detect a non NSIS-aware node by comparing the Send_TTL with the IP TTL in a received message. NTLP Length: 16 bits The total length of this NTLP message in bytes, including the common header and the variable-length objects that follow. 3.2. Object format Every object consists of one or more 32-bit words with a one word header, with the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ Luu et al. [Page 8] NTLP considerations and implementation October 2003 An object header has the following fields: Length A 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 4. Class-Num Identifies the object class. Each object class has a name, which is always capitalized in this document. An NTLP implementation must recognize the following classes: NULL A NULL object has a Class-Num of zero, and its C-Type is ignored. Its length must be at least 4, but can be any multiple of 4. A NULL object may appear anywhere in a sequence of objects, and its contents will be ignored by the receiver. IP_HOP Carries the IP addresses of the NSIS-aware nodes that sent this message. This document refers to an IP_HOP object as a PHOP ("previous hop") object for downstream messages or as a NHOP ("next hop") object for upstream messages. To avoid the ambiguity in the case of bi-directional signaling application, downstream is always considered as the direction of data flow. As a result, there are two "down streams" in a bi-directional signalling application and they do not need to be the same. TIME_VALUES Contains the value for the refresh period R used by the creator of the message. It can be required in New and Mod message. FLOW_ID Contains information about the flow which should receive a particular client treatment. It typically contains the IP addresses of the data sender and data receiver, and possibly some additional demultiplexing information (such as protocol type, source and destination ports, SPI or flow label). Luu et al. [Page 9] NTLP considerations and implementation October 2003 INTEGRITY Carries cryptographic data to authenticate the originating node and to verify the contents of this NTLP message. SESSION Identifies a signaling application session, NSLP_ID and the sequential number of session. These SESSION class objects also carry the content of the NSLP message. SESSION_FRAGMENT Carries fragments of a fragmented NSLP message. NSLP_INFO Carries the information exchanged between NSLPs of a same specific NSLP application. The information can be about overload control, topology information... This information is opaque to NTLP layer and does not need to concern with a particular signaling application session. NTLP_INFO Carries the information exchanged between NTLPs nodes. The information can be about overload control, security associations... The NTLP_INFO class objects are only in the NTLP peer scope. C-Type Object type, unique within Class-Num. 3.3. NTLP message The format of NTLP message is as follows: :: = [*][*] [][] [*][*] [] [*][*] (The "*" denotes one or more) Luu et al. [Page 10] NTLP considerations and implementation October 2003 If the INTEGRITY is present, it SHOULD immediately follow common header. The SESSION SHOULD be placed after the FLOW_ID object. An implementation should create messages with the objects in the order shown here, but accept the objects in any permissible order. There can be two IP_HOP objects in a message NTLP, but two objects MUST NOT be of the same C_TYPE. In the other cases, there can be no IP_HOP in a NTLP message if the message is sent directly between two NEs. The TIME_VALUES object is only in the message which can establish a new state on a NE. There can be more than one SESSION and SESSION_ERROR class object in a NTLP message. There SHOULD be only one SESSION_FRAGMENT object in a NTLP message. NTLP SHOULD avoid fragmenting a NSLP message into many small fragments. The length of SESSION_FRAGMENT object SHOULD be long enough to insure that the total length of a NTLP message is approximately equal to the MTU of link. NSLP_INFO objects can be placed in the messages which are sent to the NSLP peers. NTLP_INFO objects can be placed in the messages which are sent to the NTLP peers. 3.3.1. New message The New message is sent end to end. When the signaling entity NE wants to initiate a signaling application (e.g. resource reservation, Middlebox configuration), this signaling entity NE sends this message toward another signaling entity which terminates the signaling. The NE which initiates the signaling application is called NSIS Initiator (NI) and the other which terminates the signaling application is called NSIS Responder (NR). A New message is used once for a session. When a node receives a New message, it knows that the session indicated in this message is a new one. NTLP of this node must not verify if this state is established. The IP source address of a New message must be the address of the NI which has initiated the signaling application (SrcAddress of the FLOW_ID), while the destination address must be the address of the NR which terminates the signaling application (DestAddress of the FLOW_ID). These addresses insure that the message will be correctly routed through a non-NSIS cloud. If SM Luu et al. [Page 11] NTLP considerations and implementation October 2003 of the common header is not 0, New messages MUST be sent with the Router Alert IP option in their IP headers [10]. If SM is 0, New messages MAY be sent with the Router Alert IP option in their IP headers. The format of a New message is as follows: ::=[][*][] [*] [] In case SM=0, IP_HOP can be present in the New message to assure the hop by hop security. If this object is present, it must be an IP_HOP ADJACENT object (IPv4_ADJACENT or IPv6_ADJACENT). In case SM=1, there MUST be an IP_HOP ADJACENT object (IPv4_ADJACENT or IPv6_ADJACENT) in the message. In the case SM=2 and SM=3, there can be two IP_HOP class objects in the message. They must be an IP_HOP ADJACENT object (IPv4_ADJACENT or IPv6_ADJACENT) and an IP_HOP REMOTE object (IPv4_REMOTE or IPv6_REMOTE). R1 R2 R3 R4 +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | | | |+----+| ||NSLP|| | | | | ||NSLP|| || || | | | | || || || 1 || | | | | || 1 || |+----+| | | | | |+----+| | || | | | | | | || | |+----+| |+----+| |+----+| |+----+| ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ Figure 1: Soft-state in case of SM=2 and SM=3. For instance, let us assume that the New message with SM=2 (or 3) is sent through R1 to R4 in figure 1. The node R1 forwards the New message to R2. This message contains an IP_HOP_ADJACENT object with IP address=R1. When R2 receives this message, R2 can forward the message to R3. There can be two IP_HOP class objects in this message. The first object is IP_HOP ADJACENT object (IP address=R2). The second is IP_HOP REMOTE Luu et al. [Page 12] NTLP considerations and implementation October 2003 object (IP address=R1). Because SM=2 (or 3), no state is established on the NSLP1-unaware node R2. R2 keeps the address of the previous nodes NSLP-aware (i.e. R1) in this message. The purpose of using the IP_HOP REMOTE and IP_HOP ADJACENT object is to assure the hop by hop security through the stateless nodes. When R3 receives this message from R2, it knows that the previous hop is R2 and no state was established on the node R2. After receiving the transferred message sent by R2, the node R3 forwards the message to user B. This message also includes two IP_HOP class objects, the first object IP_HOP ADJACENT (IP address=R3), the second IP_HOP REMOTE (IP address=R1). TIME_VALUES object contains the value for the refresh period R for the forward state or backward state (see 3.4.5). This value is only used for the first SESSION_FULL_MSG object in the message. If the session is in a hard state, this object MUST be 0xffffffff or MUST NOT be present. FLOW_ID must be present in this message for routing purpose. If a node is non-NSIS aware, the message can be routed by another path to the destination. This path is different of the data path when the routing process is based on certain parameters (e.g. port, DSCP) rather than on the IP source address, and the IP destination address. SESSION_FULL_MSG must be present in this message. If there are more than one SESSION_FULL_MSG objects in this message, these objects MUST have the same FLOW_ID, i.e. messages of different signaling applications of a same end host can be transported in a signaling message. If the length of NSLP message is more than MTU and the DF bit is not set by NSLP, SESSION_FULL_MSG MUST be fragmented. Each fragment is placed in a SESSION_FRAGMENT object. Note that the New message is used once for a signaling session. Therefore, the first fragment is placed in the New message, but the next fragments must be placed in Mod messages. 3.3.2 Mod message If this message is sent following the direction of the data path, this message is used to modify an established forward session on the current path or to establish a forward state on a new path. If this message is sent following the opposite direction of the data path, this message is used to establish a backward state or to modify an established backward session (see 3.4.5) on the data path. Luu et al. [Page 13] NTLP considerations and implementation October 2003 3.3.2.1. Mod message in the direction of data path In this section, we describe a Mod message which follows the direction of the data path. This message is sent by the sender or sent by an intermediate NSIS-aware node. When a sender wants to modify an established session, it will send this Mod message toward the receiver to modify the established state on the data path. Note that the sender can be NI or NR. In case of bidirectional signaling applications, NR can be the data sender and this data sender transmit a Mod message to initiate a signaling application for a data flow NR to NI. However, this message can be sent by an intermediate node to an end host. For example, when a node detects a routing change, it MUST send a Mod message to the receiver on the new path. When a node receives a Mod message, it knows that the session was previously established. In case of a routing change, a node can receive a Mod message of the same state but from a new previous node. As a result, NTLP MUST check the IP-HOP object to know if there is a routing change. In figure 2, suppose that a session is established on the R1, R4, R5, R6 and receiver B. If the sender A wants to modify this established session, it will send a Mod to the receiver B. Mod ---> Mod R2 R3 Mod Mod --> +---+ +---+ ---> ---> / ----| |--| |--- Sender A R1 / +---+ +---+ \ R6 Receiver B +---+ +---+ / \ +---+ +---+ | |-----| |--- R4 R5 --| |--| | +---+ +---+ \ +---+ +---+ / +---+ +---+ NI \--| |---| |------ NR ---------- +---+ +---+ ---> \ / -----------------------/ Old route Figure 2: The route of Mod message in case of routing change When there is no routing change, the Mod follows the route through R1, R4, R5 and R6 to the receiver B. The message Luu et al. [Page 14] NTLP considerations and implementation October 2003 can be sent by R1 when it detects a routing change. In this case, R2 will receive the Mod message. Because there is no state of this session which was previously established on R2, a new state of this session will be established on R2. Therefore, when a node receives Mod message, it must verify whether the state was established before. When R6 receives the message from R3, R6 can know there was a routing change by comparing the previous hop in this message and the previous hop of the established state. The IP source address of a Mod message must be SrcAddress of FLOW_ID, while the destination address must be the DestAddress of the FLOW_ID. These addresses ensure that the message will be correctly routed through a non-NSIS cloud. If SM of the common header is not 0, Mod messages MUST be sent with the Router Alert IP option in their IP headers. Otherwise, Mod Messages can be sent with the Router Alert IP option in their IP headers. The format of a Mod message is as follows: ::=[][*][] [*] [] The description of the different objects in Mod message is the same as the description of objects in New. Note that if this message is sent by an intermediate node, the SM of the common header is certainly not equal to 0. 3.3.2.2. Mod message in the opposite direction of data path This message is sent between NTLP peers, NSLP peers or end to end. It MUST be sent with SM=0. If the message is sent to the next NTLP peer, it MUST not be sent with the Router Alert Option in the IP header. Otherwise, Router Alert Option MAY be present in the IP header. The IP destination address of the message is the address of a previous-hop node (NTLP peer or NSLP peer node), obtained from the forward state. The IP source address is an address of the node that sends the message. The format of a Mod message is as follows: Luu et al. [Page 15] NTLP considerations and implementation October 2003 ::=[][] [] * [*][*] [*][*] [*][*] [*][*] IP_HOP object can be present in this message. If it is present, it indicates the address of the interface through which the message is sent. The IP_HOP is only used to assure the hop by hop security. TIME_VALUE object contains the value for the refresh period R for backward state. This value is only used for the first SESSION_FULL_MSG object in the message. If the session indicated in the first SESSION_FULL_MSG object is hard state, this object MUST be 0xffffffff or MUST NOT be present. SESSION_FULL_MSG object must be present in the message. If there are more than one SESSION_FULL_MSG objects in this message, these objects MUST have the same FLOW_ID, i.e. messages of different signaling applications of a same end host can be transported in this signaling message. There can be SESSION_ACK objects, SESSION_REFRESH objects, SESSION_FMR objects, SESSION_TEAR objects, SESSION_ERROR objects, NSLP_INFO objects, NTLP_INFO objects in this message. These objects MUST be sent to the same next hop. 3.3.3. INFO message The INFO message can be used to send all types of NTLP objects except SESSION_FULL_MSG objects. These objects can be SESSION_ACK, SESSION_FMR, SESSION_TEAR, SESSION_ERROR class object, NSLP_INFO class objects and NTLP_INFO class objects. The objects can be placed in an INFO message. These objects can belong to different sessions. This message can be sent by an end host or an intermediate node. The INFO message is used to exchange the information between two NTLP peers, between two NSLP peers or between NI and NR. The exchanged information can be: - Acknowledge a message: To acknowledge a message, the SESSION_ACK object is used. When the NTLP of a node receives an Info message which contains a SESSION_ACK object, it MUST check whether the Luu et al. [Page 16] NTLP considerations and implementation October 2003 state of the session indicated in this object has been already established. If the state is established, NTLP will send this object to NSLP. Otherwise, NTLP of the node which receives this object MUST notify the node which has sent this object that the session is not established. The notification can be sent by using SESSION_ERROR object. - Refresh a state To refresh an established state, the SESSION_REFRESH object will be used. When a NTLP of a node receives an Info message which contains a SESSION_ACK message, it MUST check whether the state of the session indicated in this object have already established. If the state is established, the state is refreshed. Otherwise, a notification will be sent to the node which has sent this object. If the node detects there is a routing change, it can ask the node which has sent this object to send the SESSION_FULL_MSG by using SESSION_FMR to establish state on the new path. - Delete a state To delete an established state, the SESSION_TEAR can be used. Note that in the case the addressing of Info message is end to end, SESSION_TEAR object MUST not be forwarded if there is forward state for the same session but a different PHOP . This will avoid deleting the state on the new path. We distinguish two cases of addressing of this message: - Peer to peer: The destination address message is the next (NTLP or NSLP) hop address (in case the message follows the direction of data path) or the previous hop (in case the message follows the opposite direction of data path). It MUST be sent with SM=0. If these messages are sent to a next/previous NTLP peer, they MUST NOT be sent with the Router Alert IP option in their IP headers. If these messages are sent to a next/previous NSLP peer, they SHOULD be sent with the Router Alert IP option in their IP headers to assure the hop by hop security. The message can be used between two end hosts, the message is directly sent to end host without any interpretation of the intermediate nodes. Luu et al. [Page 17] NTLP considerations and implementation October 2003 - End to end : This addressing is used when the entity that sends the message does not know the address of the next NTLP (or NSLP). If SM=1, SM=2 or SM=3, the FLOW_ID MUST be present in NTLP messages. The FLOW_ID will be only used by NTLP to route the signaling message. These messages MUST be sent with the Router Alert IP option in their IP headers. * In the first case, the format of an INFO message is as follows: ::=[][] [*] [*][*] [*][*] [*][*] The message MUST be sent with SM=0. If the message is sent to a next NTLP peer, the IP_HOP object MAY NOT be present. If the message is sent to a next NSLP node, IP_HOP object is used to assure the hop by hop security. There can be SESSION_ACK objects, SESSION_REFRESH objects, SESSION_FMR objects, SESSION_TEAR objects, SESSION_ERROR objects, NSLP_INFO objects, NTLP_INFO objects. These objects must be sent to the same next hop. * In the second case, the format of an INFO message is as follows: ::=[][] [*][*] [*] FLOW_ID object MUST be present in this message for routing. There can be SESSION_REFRESH objects, SESSION_TEAR objects, NSLP_INFO objects. These objects MUST be sent to the same destination. Luu et al. [Page 18] NTLP considerations and implementation October 2003 3.4. NTLP objects 3.4.1. INTEGRITY class The integrity object includes a sequence number and a message digest useful for authenticating and validating the integrity of a NTLP message. The digest value of INTEGRITY is computed on the entire NTLP message, but no including the digest value. INTEGRITY class=1 o Keyed Message Digest INTEGRITY Object: Class =1, C-Type = 1 +-------------+-------------+-------------+-------------+ | Flags | 0 (Reserved)| | +-------------+-------------+ + | Key Identifier | +-------------+-------------+-------------+-------------+ | Sequence Number | | | +-------------+-------------+-------------+-------------+ | | + + | | + Keyed Message Digest | | | + + | | +-------------+-------------+-------------+-------------+ The fields of this object are defined in [11] O INTEGRITY_CHALLENGE Object: Class =1, C-Type = 2 +-------------+-------------+-------------+-------------+ | 0 (Reserved) | | +-------------+-------------+ + | Key Identifier | +-------------+-------------+-------------+-------------+ | Challenge Cookie | | | +-------------+-------------+-------------+-------------+ The fields of this object are defined in [11] Luu et al. [Page 19] NTLP considerations and implementation October 2003 3.4.2. IP_HOP class IP_HOP class= 2; o IPv4_ ADJACENT object: Class=2 ; C-Type=1 This object indicates IPv4 address of the interface through which the message is sent. +-------------+-------------+-------------+-------------+ | IPv4 Address | +-------------+-------------+-------------+-------------+ o IPv4_REMOTE object: Class=2 ; C-Type=2 This object indicates IPv4 address of the interface of the previous (or next) NSLP-aware node through which the message was most recently sent and at which the state was established. +-------------+-------------+-------------+-------------+ | IPv4 Address | +-------------+-------------+-------------+-------------+ o IPv6_ADJACENT object: Class=2 , C-Type = 3 This object indicates IPv6 address of the interface through which the message is sent. +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Address (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ o IPv6_REMOTE hop: Class=2 , C-Type = 4 This object indicates IPv6 address of the interface of the previous (or next) NSLP-aware node through which the message was most recently sent and at which the state was established. +-------------+-------------+-------------+-------------+ | | + IPv6 Address (16 bytes) + Luu et al. [Page 20] NTLP considerations and implementation October 2003 | | + + | | + + | | +-------------+-------------+-------------+-------------+ 3.4.3. TIME_VALUES class TIME_VALUES class=3 o TIMES_VALUES object : Class=3 ; C-Type=1 +-------------+-------------+-------------+-------------+ | Refresh period R | +-------------+-------------+-------------+-------------+ The refresh period R is used to generate this message in milliseconds. 3.4.4. FLOW_ID class FLOW_ID class = 4 o IPv4 with ports FLOW_ID Object: Class =4 , C-Type = 1 +---------------+---------------+---------------+---------------+ | IPv4 SrcAddress | +---------------+---------------+---------------+---------------+ | IPv4 DestAddress | +---------------+---------------+---------------+---------------+ | SrcPort | DstPort | +---------------+---------------+---------------+---------------+ | Protocol Id | // | +---------------+---------------+---------------+---------------+ o IPv4 with IPsec FLOW_ID Object: Class =4 , C-Type = 2 +---------------+---------------+---------------+---------------+ | IPv4 SrcAddress | +---------------+---------------+---------------+---------------+ | IPv4 DestAddress | +---------------+---------------+---------------+---------------+ | SPI | +---------------+---------------+---------------+---------------+ | Protocol Id | // | +---------------+---------------+---------------+---------------+ Luu et al. [Page 21] NTLP considerations and implementation October 2003 o IPv6 FLOW_ID Object: Class = 4, C-Type = 3 +---------------+---------------+---------------+---------------+ | | + + | IPv6 SrcAddress (16 bytes) | + + | | + + | | +---------------+---------------+---------------+---------------+ | | + + | IPv6 DestAddress (16bytes) | + + | | + + | | +---------------+---------------+---------------+---------------+ | // | Flow Label (20 bits) | +---------------+---------------+---------------+---------------+ 3.4.5. SESSION class SESSION class=5 o SESSION_FULL_MSG: Class=5, C-type=1 This object is used to identify globally a session of a signaling application. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luu et al. [Page 22] NTLP considerations and implementation October 2003 NSLP_ID: identification of a specific NSLP Flag: 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | | |H|D|A| | |D|B|T|F|C| | | | | | |K| | +-+-+-+-+-+-+-+-+ D: Direction: D=0: the direction of the NSLP message is the same as data flow direction D=1: the direction of the NSLP message is in the opposite direction of data flow In this document, there are two states in a session: forward state and backward state. These two states are identified by the bit D of SESSION_FULL_MSG. The forward state is identified by no setting bit (D=0) and the backward state is marked by setting D=1. The forward state is usually created before the backward. The backward state is not always created. If forward state of a session is deleted, the backward state of that state is also deleted. However, if the backward is deleted, forward state of a session still exists. B: bi-directional In this document, we assume that NI (NSIS initiator) is always the entity which firstly initiates the signaling and NR (NSIS Responder)is always the entity which responds to the messages from NI. NI and NR can be sender and receiver. B=0: session from NI to NR. B=1: session from NR to NI. HT: Hard state. If this bit is set, the state is only deleted by an explicit TEAR message. Luu et al. [Page 23] NTLP considerations and implementation October 2003 DF: Don't fragment If this bit is set, the SESSION full message object must be not fragmented by NTLP. ACK: Acknowledge If the entity sending this message wants to receive the acknowledge of this message, this bit will be set MAC Address: MAC Address of the host that initiates this message Random number (NSLP session): The random number which is created by the host (or node) initiating this message. This number can be considered as the number of a session of a same NSLP in a host (or node) initiating this message State sequential number: The sequential number of NSLP messages of a signalling application session. This number changes incrementally when NSLP sends a new message of a same session. The number of forward state and the number of backward state are independent of each others. NSLP Message contents: Content of the NSLP message and the content is opaque to NTLP. The NSLP_ID, MAC address, Random number can be considered as the session identifier of a session. The state sequential number can be considered as the message sequential number or sequential number of session state. O SESSION_ACK: Class=5, C-type=2 This object is used to confirm the reception of a SESSION_FULL_MSG object. Luu et al. [Page 24] NTLP considerations and implementation October 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NSLP_ID : identification of a specific NSLP Flag : 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | | |H| | | | |D|B|T| | | | | | | | | | | +-+-+-+-+-+-+-+-+ D : Direction : The value of this bit is copied from the SESSION_FULL_MSG object D=0 : the direction of the NSLP message is the same as data flow direction D=1 : the direction of the NSLP message is in the opposite direction of data flow B: bi-directional The value of this bit is copied from the SESSION_FULL_MSG B=0: session from NI (NSIS initiator) to NR (NSIS Responder) B=1: session from NR to NI Luu et al. [Page 25] NTLP considerations and implementation October 2003 HT: Hard state. The value of this bit is copied from the SESSION_FULL_MSG. If this bit is set, the state is only deleted by an explicit TEAR message. MAC Address: MAC Address of the host that initiates this message. The value of this field is copied from the SESSION_FULL_MSG. Random number (NSLP session): The random number which is created by the host (or node) initiating this message. This number can be considered as the number of a session of a same NSLP in a host (or node) initiating this message. The value of this field is copied from the SESSION_FULL_MSG. State sequential number : The sequential number of NSLP messages of a signalling application session. This number changes incrementally when NSLP sends a new message of a same session. This number of forward state and the number of backward state are independent of each others. The value of this field is copied from the SESSION_FULL_MSG. o SESSION_REFRESH Class=5, C-type=3 This object is used to refresh an established state. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luu et al. [Page 26] NTLP considerations and implementation October 2003 Definition is the same as the SESSION_ACK object. o SESSION_FMR (Full Message Required): Class=5, C-type=4 When a NE receives a SESSION_REFRESH of a state which has not been established, NE uses this object to require a full message to establish a new state. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Definition is the same as the SESSION_ACK object. o SESSION_TEAR Class=5, C-type=5 This object is used to delete an established state. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Definition is the same as the SESSION_ACK object. Luu et al. [Page 27] NTLP considerations and implementation October 2003 3.4.6. SESSION_ERROR class SESSION_ERROR Class=6 o SESSION_ERROR Class=6, C-type=1 This object is used to inform a notification or an error of a specific session of signaling application. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Error of the signaling application session // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Definitions of other fields are the same as the SESSION_ACK object. 3.4.7. SESSION_FRAGMENT class SESSION_FRAGMENT class=7 o SESSION_FRAGMENT object: Class=7, C-type=1 This object contains a fragment of the fragmented NSLP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved |Fragment Offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Header of SESSION_FULL_MSG object | Luu et al. [Page 28] NTLP considerations and implementation October 2003 + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Fragment of NSLP Message contents + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag: 0x00: last fragment: This fragment is the last fragment of a fragmented NSLP message. 0x01: more fragment: This fragment is not the last fragment. There will be other fragments of the fragmented NSLP message. Fragment Offset: This field indicates where in the SESSION_FULL_MSG object this fragment belongs to. Header of SESSION_FULL_MSG object: The header of SESSION_FULL_MSG which contains NSLP_ID, flag, MAC, Random number (NSLP session), State sequential number. Fragment of NSLP Message contents: The fragment of fragmented NSLP message content of the SESSION_FULL_MSG object. 3.4.8. NSLP_INFO class NSLP_INFO class=8 The object of this class is used to transport the information between the NSLP-aware peer nodes, e.g. NSLP overload. The objects of this class are for further study. 3.4.9. NTLP_INFO class NTLP_INFO class=9 Luu et al. [Page 29] NTLP considerations and implementation October 2003 The objects of this class are used to transport the information between the NTLP-aware peer nodes, e.g. NTLP overload, establishment of security associations... The objects of this class are for further study. 4. NTLP and NSLP In this section, we use the proposed NTLP protocol to support two signaling applications. These are resource reservation in IntServ environment and middlebox configuration application. The analysis of the signaling applications is focused on NLTP rather than on NSLP. 4.1. Using NTLP for resource reservation in IntServ environment NTLP is used to reserve resource in IntServ environment following two approaches. There are sender-initiated and receiver-initiated approaches. A sender-initiated approach is when the sender of the data flow requests and maintains the resource reservation used for that flow. In a receiver-initiated approach the receiver of the data flow requests and maintains the resource reservation used for that flow. This section proposes how sender-initiator and receiver-initiator approaches can be achieved. However, this does not mean these are two different reservation signaling applications. The bi-directional reservation can be done by using the B bit of SESSION object. 4.1.1. Receiver-initiated approach We call signaling application for resource reservation receiver-initiated NSLP_QoS_R. NSLP_QoS_R has its own messages. We suppose that all of the messages of RSVPv1 in RFC2205 [1] are reused. These messages are Path, Resv, PathTear, ResvTear, PathError, ResvError, ResvConf. We suppose that there are nodes R1, R2, R3, R4, R5, R6 between a sender and a receiver and these nodes support NSLP_QoS_R (Figure 3). Luu et al. [Page 30] NTLP considerations and implementation October 2003 Mod(Resv) <<--- Mod(Resv) New (Path) Mod(Resv) Mod(Resv) Mod(Resv) <<--- ---> <<--- <<--- <<--- New(Path) R3 R4 New(Path) New(Path) New(Path) --> +----+ +----+ ---> ---> ---> / ---| |---| |--- NI R1 R2 / +----+ +----+ \ NR +----+ +----+ +----+ / \ +----+ | |----| |-----| |--- R5 R6 ---| | +----+ +----+ +----+ \ +----+ +----+ / +----+ Sender \--| |---| |--- Receiver +----+ +----+ Figure 3: The simple schema for illustrating NSLP_QoS_R 4.1.1.1. Path message The sender (NI) sends a Path message to the receiver (NR). This message is placed in the message New of NTLP since a new session has to be established. The format of the message New(Path): ::= [] [*] [] o Common header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x01 | Flag | NTLP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send_TTL | Reserved | NTLP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers=1 : Version of NTLP is 1 M_Type=1: Message Type is New Flag : SM=1 : NTLP state MUST be established on all NTLP-aware nodes. Note that if NTLP state is still established on NSLP_QoS_R-unaware node. NTLP will save the content of NSLP message and forward this Luu et al. [Page 31] NTLP considerations and implementation October 2003 message to NR when the node detects a routing change. o the address of the interface through which the New message is sent o Contains the value for the refresh period R for forward state. This value is only used for the first SESSION_FULL_MSG object in the message. o the identification of the data flow between sender and receiver. o *: this object contains the content of the Path message. Note that The New message can contain objects of other signaling applications, but they must belong to the same FLOW_ID. The SESSION_FULL_MSG 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents of Path message // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NSLP_ID is NSLP_QoS_R Flag: 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | | |H|D|A| | |D|B|T|F|C| | | | | | |K| | +-+-+-+-+-+-+-+-+ D=0: the forward state Luu et al. [Page 32] NTLP considerations and implementation October 2003 B=0: the session from NI to NR. HT=0: soft state is used DF: If Path message can be fragmented, DF=0. In this case, when the total length of New message is more than MTU of link NI and R1, the message Path is fragmented. The fragments of Path message will be placed in the SESSION_FRAGMENT objects and NTLP in the R1 is responsible for assembling these fragments. Note that the first fragment is sent in a message NEW, the others must be sent in a Mod message. ACK: If NI wants to receive an acknowledgment of this message, this bit is set. Otherwise, it is not set. Random number (NSLP session): The random number which is created by the NI (or node) initiating this message. This number can be considered as the number of a session of a same NSLP in a host (or node) initiating this message. State sequential number: This number is initiated by sender. It can be a random number or 0. When a node receives this New message, forward state is established and the Path message is sent by NTLP to NSLP_QoS_R. After the state is established from NI to NR, if there is a routing change at a node, this node must send immediately a Mod message following the new path. For example, supposing that the message New follows the path through R1, R2, R3, R4 to receiver. The routing in the node R2 has changed (figure 3). The signaling message is routed to R5. When R2 knows the routing change, it must send a MOD message to R5 to establish the state on the new path. If the sender wants to modify the established session, it sends a Mod message. This Mod message is the same as the New message but the state sequential number in the SESSION_FULL_MSG incrementally changes. o : If the NSLP message is more than MTU, the message can be fragmented. The first fragment is carried in SESSION_FRAGMENT object in the New message. The next Luu et al. [Page 33] NTLP considerations and implementation October 2003 fragments are carried in SESSION_FRAGMENT object in Mod messages. 4.1.1.2. Resv message If NR wants to initiate the reservation, it sends the Resv message to the previous node (i.e. R4) until it arrives at NI. The Resv message is sent in a Mod message. The IP source address is the address of the node sending this message. The IP destination address is the address of the previous NTLP aware node. The format of a Mod message is as follows: ::=[] [*][] [*][*] [*][*] [*][*] [*] o Common header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x02 | Flag | NTLP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send_TTL | Reserved | NTLP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers=1 : Version of NTLP is 1 M_Type=2: Message Type is Mod Flag : 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | SM | | +-+-+-+-+-+-+-+-+ SM=0 : the message is sent directly to previous hop. o the address of interface through which the message is sent. Luu et al. [Page 34] NTLP considerations and implementation October 2003 o Contains the value for the refresh period R for backward state. This value is only used for the first SESSION_FULL_MSG object in the message. o : this object must be present in this message. This object contains the Resv message. In this Mod message, there can be other objects in this message such as SESSION_ACK, SESSION_TEAR, SESSION_FMR, SESSION_REFRESH, SESSION_ERROR, NSLP_INFO, NTLP_INFO objects. These objects are sent to the same node. The SESSION_FULL_MSG : 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP_ID | Flags | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents of Resv message // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NSLP_ID is of NSLP_QoS_R. Flag : 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | | |H|D|A| | |D|B|T|F|C| | | | | | |K| | +-+-+-+-+-+-+-+-+ D=1: the backward state B=0: the session from NI to NR. HT=0: soft state is used DF: If NSLP allows NTLP to fragment the NSLP message, this bit is not set. Luu et al. [Page 35] NTLP considerations and implementation October 2003 ACK: If the receiver wants to receive an acknowledgment of this message, this bit is set. State sequential number is initiated by receiver. It can be a random number or 0. Other objects: other objects that are to be sent to the same node can be sent in this message. The ACK object to inform the acknowledgment of Path message can be placed in this message if the acknowledgement must be received by the intermediate nodes (i.e. R4, R3, R2, R1). 4.1.1.3. Other messages The other messages of RSVP such as Refresh, Error, ACK, NACK, PathTear, ResvTear, ResvConf can be sent in a INFO message. In the case the addressing of Info message is peer to peer, the format of Info message is as follows: ::=[][][*] [*][*] [*][*] SESSION_ACK object is used to inform the acknowledgment of SESSION_FULL_MSG object. SESSION_REFRESH object is used to refresh the forward and backward established state. SESSION_FMR object is used to ask a full message because the state has not been established yet. SESSION_TEAR object is used to delete an established state. SESSION_ERROR object is used to inform the notification or the error of the session. In the case the addressing of Info message is end to end, the format of Info message is as follows: ::=[][] [*][*][*] The end to end addressing is used if a NE does not know the address of the next NE to send this message. For example, in the case the forward state is established on the data path but the backward state has not established yet (e.g. The receiver Luu et al. [Page 36] NTLP considerations and implementation October 2003 (NR) still does not send Resv to reserve the resource), NI must send the Refresh object in Info whose addressing is end to end. In this message, FLOW_ID must be present for routing the message. In case the acknowledgment is not necessarily received by intermediate nodes, it can be sent in an Info message directly from NI to NR and vice versa. The means the IP source address of the message is the address of the NI (or NR) node sending this message, the IP destination address is the address of the NR (or NI) and SM of the common header of the message is 0. 4.1.2. Sender-initiated approach We refer to signaling application for resource reservation sender-initiated NSLP_QoS_S. NSLP_QoS_S has its own message. We suppose that there are Path, PathTear , ACK, Refresh in this signaling application. Path message is used to discover a path to destination and reserve resource on this path. ACK message is used to inform the reception of receiver. PathTear is used to delete the state on the established path. 4.1.2.1. Path message The sender (NI) sends a message Path to the receiver. This message is placed in the message New of NTLP since a new session has to be established. The format of the message New is as follows: ::=[] [*][[] This message is the same as the New message in the 4.1.1.1 4.1.2.2. ACK message The message ACK is placed in the INFO message. Description and value of objects of this message are the same as 4.1.1.3 4.1.2.3. PathTear message To delete a state, a SESSION_TEAR object of the established session is placed in an INFO message. The message is sent Luu et al. [Page 37] NTLP considerations and implementation October 2003 forward receiver. 4.1.2.4. Bi-directional reservation The bidirectional receiver-initiated reservation is not efficient. It takes at least three RTT to implement the bidirectional reservation. This section is only concerned to bi-directional sender-initiated reservation. The bidirectional sender-initiated reservation functionality is similar to a combination of two unidirectional reservation functionalities that are accomplished in opposite directions. The NI sends New(Path) message to NR to reserve resource from NI to NR. When this message arrives at NR, NR sends back a Mod(Path) to reserve the resource on the path from NR to NI. The acknowledgement of the New(Path) message can be sent in this message, but it MUST be placed in the NSLP message. Because of the asymmetric routing, SESSION_ACK object of the reservation session from NI to NR can not be placed in this message since the forward state is not established on the data path from NR to NI. As a result, NTLP must use a Info message to acknowledge a message or NSLP implements acknowledge of a message within itself. Note that the session of reservation from NR to NI is marked by B (B=1) bit in the SESSION_FULL_MSG object. 4.2. NTLP for Middlebox configuration In this section, we use the messages of [12] to signal information to firewall and NAT. We call signaling application for Midcom NSLP_Midcom. We do not analyze [12], this is only an example to show how the proposed NTLP can support Middlebox configuration. The messages of [12] are Path, Create, Response, Query, and Release. In fact, NSLP_Midcom is not installed on all routers on the data path. This application is not 'sensible' to routing change because it is only installed on a gateway or an edge router. Therefore, it must not be installed on all the NTLP-aware devices on the data path. The state should be established only on NSLP_Midcom aware nodes. For this case, using SM=2 or SM=3 is useful. 4.2.1. Path message Message Path is placed in the message New of NTLP. Luu et al. [Page 38] NTLP considerations and implementation October 2003 The format of the message NEW: ::= [] [*] [] o Common header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x01 | Flag | NTLP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send_TTL | Reserved | NTLP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers=1: Version of NTLP is 1 M_Type=1: Message Type is New Flag : 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | SM | | +-+-+-+-+-+-+-+-+ SM=02( or SM=3): State is only established in NSLP_Midcom nodes on the data path o the address of sender or interface of NSLP-Midcom-aware node through which the message is sent. o Contains the value for the refresh period R for forward state. This value is only used for the first SESSION_FULL_MSG object in the message. o the identification of the data flow between sender and receiver. o : this object contains the content of message PATH. In fact, there can be more than one of other signaling application in this NEW message, but they must belong to the same FLOW_ID. o : If the NSLP message is more than MTU, the message can be fragmented. The first fragment is carried in SESSION_FRAGMENT object in the New message. The next Luu et al. [Page 39] NTLP considerations and implementation October 2003 fragments are carried in SESSION_FRAGMENT object in Mod messages. 4.2.2. Create message If the Create message is used to initiate the session (sender-initiated), this message must be placed in the New message. The description of message New is the same as the New message in 4.2.1. If the Create message is used in mode receiver-initiated, it must be placed in Mod message. Mod message that transports Create is the same as the Mod message in 4.1.1.2. 4.2.3. Release message A Release message is used to delete installed NSLP state at a firewall and to release a NAT binding without waiting for a soft-state timeout. This message can be done by sending a SESSION_TEAR object in an INFO message. 4.2.4. Query A QUERY message triggers a RESPONSE message to return installed state information. The main purpose of this message is to provide diagnostic facilities. This message can be done by sending a SESSION_FULL_MSG object in a Mod message. The content of this object is to ask the NSLP_Midcom-aware nodes to turn back the state information. 4.2.5. Response A RESPONSE message is either sent to acknowledge a previous message or to indicate an error. This message can be done by sending a SESSION_ACK or SESSION_ERROR object in an INFO message. 4.2.6. Trigger message The TRIGGER message is an asynchronous event notification sent by a NSLP_Midcom aware node. Unlike the CREATE message it does not create or modify NSLP state at nodes between the initiator and the target of the TRIGGER. This message can be done by sending a Mod message from an Luu et al. [Page 40] NTLP considerations and implementation October 2003 NSLP_Midcom aware intermediate node to an end host. The SM of common header of this message must be 0. 5. Security considerations The security is based on hop by hop. In the case SM=0,SM=2 or SM=3, we can use two IP_HOP ADJACENT and IP_HOP REMOTE objects to maintain the hop by hop security. This document does need further security analysis. 6. Conclusions In this document, we present our consideration of NTLP and give a proposal of NTLP protocol. NTLP is the lower layer of NSIS signaling protocol. Therefore, the NTLP must be generic and efficient? to support the signaling applications. When we design this protocol, we think everything is object. A signaling message can contain many objects to reduce processing overhead requirements. An object can be used without other to complete its meaning. The SESSION_TEAR, SESSION_ACK, SESSION_FRM, SESSION_ERROR objects are used for this purpose. The state management is described in detail in this document. NTLP supports state management for NSLP signaling applications. NTLP can establish state even though it does not support a specific NSLP (SM=1). When the NTLP detects a routing change, it can send the trigger message before towards the NI (or NR). However, NSLP can decide if it needs NSLP support state management (SM=2 or SM=3). The state management is described in detail in this document. The state management can be implemented by all NTLP-aware nodes on the data path even though it does not support a specific NSLP (SM=1). When the NTLP detects a routing change, it can send the trigger message which was received before towards the NI (or NR). However, the NSLP can decide if it needs NSLP support state management (SM=2 or SM=3). In all cases, the NTLP is always in charge of soft state management. NTLP refreshes states and informs NSLP about the routing change. Two state of a session are defined: forwarding state and backward state. The forward state is usually created before the backward. The backward is not always created. If forward state of a session is deleted, the backward state of that state is also deleted. However, if the backward state is deleted, forward state can still exist. Luu et al. [Page 41] NTLP considerations and implementation October 2003 Reference 1. R. Braden et al, "Resource Reservation protocol" Version 1 Functional Specification RSVP, RFC2205, September 1997 2. L. Berger et al, "RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001. 3. M. Brunner, "Requirements for Signaling Protocols", work in progress, draft-ietf-nsis-req-09.txt, August 2003 4. R. Hancock et al, "Next Step in Signaling: Framework", work in progress, draft-ietf-nsis-fw-02.txt, March 2003. 5. N. BOUKHATEM et al, "IP Signaling : Requirements", livrable of IPSIG project, May 2003 6. S. Bradner,, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7. Melinda Shore, "The NSIS Transport Layer Protocol (NTLP)", draft-shore-ntlp-00.txt", work in progress. May 2003 8. H. Schulzrinne et al, "CASP - Cross-Application Signaling Protocol", work in progress, draft-schulzrinne-nsis-casp-01.txt, March 2003 9. L. Westberg et al, "A Proposal for RSVPv2-NSLP", work in progress, draft-westberg-proposal-for-rsvpv2-nslp-00.txt, April 2003. 10. Katz, D., "IP Router Alert Option", RFC2113, February 1997 11. F. Baker et al, RSVP Cryptographic Authentication, RFC2747, January 2000 12. H. Tschofenig et al,'A Firewall/NAT Traversal Client for CASP', work in progress, draft-tschofenig-nsis-casp-midcom-01.txt, March 2003 Acknowledgements We would like to thank Robert Hancock, Melinda Shore, Ilya Freytsis, John Loughney, Ruediger Geib, Hannes Tschofenig, Henning Schulzrinne, Attila Bader, Georgios Karagiannis, Sven Van den Bosch and all NSIS members. All of you always have the answers for our questions. It is always a pleasure to discuss the signalling problems with you. We would like to thank IPSIG members for their contributions in this draft. Luu et al. [Page 42] NTLP considerations and implementation October 2003 Authors' Addresses Thanh Tra Luu Ecole Nationale Superieure des Telecommunications Departement Informatique-Reseaux 46 Rue Barrault 74013 Paris - FRANCE Phone: (+33) (-0)1 45 81 71 06 Email: luu@enst.fr Nadia Boukhatem Ecole Nationale Superieure des Telecommunications Departement Informatique-Reseaux 46 Rue Barrault 74013 Paris - FRANCE Phone: (+33) (-0)1 45 81 82 16 Email: Nadia.Boukhatem@enst.fr Guy Pujolle University of Pierre et Marrie Curie Laboratoire d'Informatique de Paris 6 Theme Reseaux-Performances 8 Rue du Capitaine Scotte 75015 Paris - FRANCE Phone: (+33) (-0)1 44 27 75 14 Email: Guy.Pujolle@lip6.fr Vedat YILMAZ THALES Communications 160, boulevard de Valmy 92704 Colombes Phone: (+33) (-0)1 46 13 34 68 EMail: vedat.yilmaz@fr.thalesgroup.com Yacine El Mghazli Alcatel R&I Route de Nozay F-91460 Marcoussis - FRANCE Phone: (+33) (-0)1 69 63 41 87 Email: yacine.elmghazli@ms.alcatel.fr Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Luu et al. [Page 43] NTLP considerations and implementation October 2003 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.