NSIS WG Internet Draft Thanh Tra Luu Exprires: November 2004 Nadia Boukhatem ENST Paris G. Pujolle University of Paris 6 V. Yilmaz THALES Communications, LIP6 Y. EL Mghazli Alcatel May 2004 NSIS Transport Layer Protocol Considerations and Implementation draft-luu-ntlp-con-imp-01.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 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 signaling messages. NSLP (NSIS Signaling Layer Protocol) is the upper layer that contains functionality such as message formats and sequences, specific to a particular signaling application. This document outlines an implementation proposal of NTLP that can Luu et al. [Page 1] NTLP Considerations and Implementation May 2004 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 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. NTLP: requirements and considerations. . . . . . . . . . . . . . 3 2.1. Soft-state management. . . . . . . . . . . . . . . . . . . . 4 2.2. Identification. . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Relationship between NTLP and underlying layer. . . . . . . . 6 2.3.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 Congestion control. . . . . . . . . . . . . . . . . . . . . 7 3. NSIS Transport Layer Protocol Specification at a glance . . . . . 7 3.1 State management . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 SM=0. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2 SM=1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3 SM=2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4 SM=3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.5 SM=4. . . . . . . . . . . . . . . . . . . . . . . . . . . .10 3.2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 New message. . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2 Mod message. . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3 Info message. . . . . . . . . . . . . . . . . . . . . . . .13 3.3 Refresh mechanism. . . . . . . . . . . . . . . . . . . . . . .13 3.4 Reliable message delivery . . . . . . . . . . . . . . . . . . 14 3.5 Security protection. . . . . . . . . . . . . . . . . . . . . .15 3.6 Path MTU discovery and fragmentation. . . . . . . . . . . . . 15 4. NSIS Transport Layer Protocol Specification. . . . . . . . . . . .16 4.1. Common header. . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Object format . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. NTLP message . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3.1. New message . . . . . . . . . . . . . . . . . . . . . . 22 4.3.2 Mod message . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.2.1. Mod message in the direction of data path. . . . . . 24 4.3.2.2. Mod message in the opposite direction of data path. .25 4.3.3. INFO message . . . . . . . . . . . . . . . . . . . . . . 26 4.4. NTLP objects. . . . . . . . . . . . . . . . . . . . . . . . .28 4.4.1. INTEGRITY class . . . . . . . . . . . . . . . . . . . . .28 4.4.2. IP_HOP class . . . . . . . . . . . . . . . . . . . . . . 29 4.4.3. TIME_VALUES class . . . . . . . . . . . . . . . . . . . 30 4.4.4. FLOW_ID class . . . . . . . . . . . . . . . . . . . . . .30 4.4.5. LINK_MTU_S . . . . . . . . . . . . . . . . . . . . . . . 31 4.4.6. LINK_MTU_R . . . . . . . . . . . . . . . . . . . . . . . 31 4.4.7 SESSION class . . . . . . . . . . . . . . . . . . . . . . 32 4.4.8 SESSION_FULL_MSG class . . . . . . . . . . . . . . . . . .34 4.4.9 SESSION_TEAR class . . . . . . . . . . . . . . . . . . . 35 4.4.10 SESSION_FMR (Full Message Required) class . . . . . . . 36 4.4.11 SESSION_ERROR class. . . . . . . . . . . . . . . . . . . 36 Luu et al. [Page 2] NTLP Considerations and Implementation May 2004 4.4.12 SESSION_ACK class. . . . . . . . . . . . . . . . . . . . 37 4.4.13 SESSION_REFRESH class . . . . . . . . . . . . . . . . . .38 4.4.14 SESSION_FRAGMENT class . . . . . . . . . . . . . . . . . 39 4.4.15 NSLP_INFO class . . . . . . . . . . . . . . . . . . . . .40 4.4.16 NTLP_INFO class . . . . . . . . . . . . . . . . . . . . .40 5. NTLP and NSLP. . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1. Using NTLP for resource reservation in IntServ environment. .40 5.1.1. Receiver-initiated approach. . . . . . . . . . . . . . . 41 5.1.1.1. Path message . . . . . . . . . . . . . . . . . . . . . 41 5.1.1.2. Resv message . . . . . . . . . . . . . . . . . . . . . 43 5.1.1.3. Other messages . . . . . . . . . . . . . . . . . . . . 44 5.1.2. Sender-initiated approach . . . . . . . . . . . . . . . .45 5.1.2.1. Path message . . . . . . . . . . . . . . . . . . . . . 45 5.1.2.2. ACK message . . . . . . . . . . . . . . . . . . . . . .45 5.1.2.3. PathTear message . . . . . . . . . . . . . . . . . . . 45 5.1.2.4. Bi-directional reservation . . . . . . . . . . . . . . 45 5.2. NTLP for Middlebox configuration . . . . . . . . . . . . . . 46 5.2.1. Path message . . . . . . . . . . . . . . . . . . . . . . 46 5.2.2. Create message . . . . . . . . . . . . . . . . . . . . . 47 5.2.3. Release message . . . . . . . . . . . . . . . . . . . . .48 5.2.4. Query . . . . . . . . . . . . . . . . . . . . . . . . . .48 5.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.6. Trigger message . . . . . . . . . . . . . . . . . . . . .48 6. Security considerations . . . . . . . . . . . . . . . . . . . . .48 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53 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 and should be independent of any particular signaling application. -NSLP: NSIS Signaling Layer Protocol is the upper layer that 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 Luu et al. [Page 3] NTLP Considerations and Implementation May 2004 one that 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 signaling applications. As a result, the NSIS Group spent a lot of time to decide which layer is responsible for which function. In this document, we propose a protocol matching to the NTLP protocol. This protocol is implemented based on the requirements of [Bru03] and the guidelines in the framework of NSIS [Han03] and the discussion in the NSIS working group. There is no new requirement that is defined in this document. 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 an effort to synthesize the discussion in the working group and to develop NTLP as a generic transport signaling protocol. This proposal of NTLP is rather different from [Sch03] and [Sho03]. However, it is designed with a great reference to [Bra97] [Ber07] [Sho03]. 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 gives a general view of NTLP specifications. The third 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 [Bru03] [Han03] [Bou03]. 2. NTLP: requirements and considerations In this section, we present our considerations concerning 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 in which an explicit command to delete an established state cannot be done (e.g. interruption of connection, a router on the path unexpectedly shuts down). The RSVP protocol [Bra97] [Ber01] is an excellent example of soft-state protocol. 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. Note that, this state can be also explicitly deleted. NSIS signaling must support soft-state for signaling applications. It means that NSIS entity (NE) can send and receive refresh messages to maintain an established state. 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 do not establish state (e.g. stateless nodes) for a specific signaling application [Wes03]. Luu et al. [Page 4] NTLP Considerations and Implementation May 2004 A NSIS aware node can establish state for a NSLP signaling application that the node does not support. This allows the intermediate NEs nodes to detect and notify network changes (e.g. routing change), errors (e.g. overload) in the network. This will increase the load on intermediate nodes. As a result, this should use for signaling applications that are sensible to network changes as resource reservation. If a routing change is detected, the node will notify the other nodes or sends NSLP message (in case the content of the NSLP message is registered). In this document, the protocol also supports hard state. That means the state is only deleted by an explicit message. 2.2. Identification In [Bru03] [Han03], NSIS introduces three identifiers for a NSIS signaling as flow identifier, session identifier and NSLP identifier. The key identification which was defined in [Bar00] is used with IP address of sender to identify uniquely the security association. The correlation identifier is proposed in [Ham03]. This information is used by the Policy Server to correlate the resource reservation request with the media authorized during session set up. The information is concerned to signaling application rather than transport function so it is not considered here. Flow identifier (FLOW_ID): FLOW_ID is used to identify a flow in a unique way. The information that could be used in FLOW_ID may include source IP address, destination IP address, protocol identifier, port, SPI, DSCP/TOS field, flow label (IPv6). 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. Session identifier (SESSION_ID): 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 of the different flows with the same network 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 Luu et al. [Page 5] NTLP Considerations and Implementation May 2004 random number (32 bits, 64 bits, 128 bits) or combining a random number with the IP source or destination address [Sho03][Sch03]. 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 the security point of view, if a hacker eavesdrops the SESSION_ID of a user and creates the same SESSION_ID number, he can interfere or control the established session. In [Tsc03], two types of solution are proposed: local solutions (authorization token, centralized entity...) and global solutions (public key, hash series and confidentiality protection). The most interesting point we get is we cannot let users create the SESSION_ID only by themselves without any authorization. In case of mobility, the care of address of a mobile node (MN) can be changed (e.g. handover). However, the home address of a MN cannot be changed without interruption of end to end connection. Therefore, the home address it can be used as SESSION_ID. This will prevent the collision cases where the SESSION_IDs of different signaling sessions can be the same; this also prevents the potential attacks to the signaling session. Note that a host can open more than one session, so home address must be concatenated with other parameters to identify a signaling session. A question that has been raised is who will create the SESION_ID for a signaling application, which entity (NI, NR or a third party) will create the SESSION_ID? In NAT/FW application, NR will configure NAT/FW in its domain before this NAT/FW can accept signaling messages from NI. In this case, NR can create the SESSION_ID and send it to NI who will initiate the signaling application session. When the NAT/FW receives signaling messages from NI, it does not create a new state for this session. In QoS NSLP [Sve03], NI will create the SESSION_ID and send it in the signaling message towards NR. NSLP identifier (NSLP_ID): Since the NTLP can support several NSLP signaling applications, 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, a node can immediately forward signaling messages of a NSLP if it does not support this NSLP. In some cases, there can be more than NSLP_ID for one flow. For example, in case a NI wants to require two signaling application for Luu et al. [Page 6] NTLP Considerations and Implementation May 2004 the same flow (e.g. NAT/FW_NSLP [Sti03] which opens the pinholes and QoS_NSLP [Sve03] which reserve network resource for the user application), two SESSION_ID can be created for two signaling applications. However, this is still an open issue. Key Identification (KEY_ID): KEY_ID is a number that is unique for a given sender. The combination of the Key Identifier and the sending system's IP address uniquely identifies the security association. In case of mobility, the IP address (Care of Address) can be changed but the connection must not be interrupted. Therefore, the SESSION_ID and KEY_ID can be used to uniquely identify the security association. 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 by 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. In case the signaling protocol uses underlying protocols with transport functions (e.g. TCP/SCTP), theses functions can be reused to support signaling applications. It is easier than implement these functions within NTLP and NSLP. Moreover, much time and effort can be saved thanks to reusing these functions. However, in this case, using the transport protocols will take more than 1/2 round trip to establish a signaling session on two peers where the state is established and 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). 2.3.1 Fragmentation When one IP node (IPv4/IPv6) has a large amount of data to send to another node, the data is transmitted in a series of IP packets. It is usually preferable that these packets be of the largest size that can successfully traverse the path from the source node to the destination node. This packet size is referred to as the Path MTU (PMTU), and it is equal to the minimum link MTU of all the links in a path. The mechanism for discovering the PMTU is standardized for IPv4 by [Mog90] and for IPv6 by [McC96]. However, in case we use the destination address to route the signaling, we cannot use these mechanisms to detect the MTU of the link between two intermediate nodes. The reason is simple because the "Packet Too Big" ICMP message will be sent to data sender instead of the node that sent signaling message (see the figure Luu et al. [Page 7] NTLP Considerations and Implementation May 2004 below) NI R1 R2 NR +---+ +---+ +---+ +---+ | |---...-| |-----...---| |---...---| | +---+ +---+ +---+ +---+ Figure 1: Path MTU discovery problem of NTLP. After processing the signaling message, R1 forwards it toward NR. In case R2 cannot continue forwarding the signaling message (packet size is too big), the "Packet Too Big" ICMP will be directly sent to NI and R1 cannot perceive it. In the document, we also propose a simple solution for this problem (see the next parts). 2.3.2 Congestion control It would be mandatory to implement the congestion control in NSIS protocol to avoid the instability of traffic. If the signaling protocol uses TCP/SCTP as an underlying transport protocol, these protocols can provide the mechanisms for congestion control. However, if other transport protocols as UDP (e.g. for next hop detection) are used, there must be congestion control mechanisms these protocols and TCP/SCTP rather than only trusting on the TCP/SCTP mechanisms. 3. NSIS Transport Layer Protocol Specification at a glance 3.1 State management The state management (SM) is indicated in the header of each NTLP message. It indicates where a state is established along the data path for any generic signaling application. Four SM values are defined. 3.1.1 SM=0 SM=0 can be used for directly sending signaling messages between two NEs without interference of intermediate nodes. The message is forwarded by intermediate nodes without establishing state. A message sent with SM=0 MAY have a router alert option (RAO) in its IP header to assure the hop by hop security or for other purposes. The IP source and destination address are the address of the entity that sends and receives the message respectively. Luu et al. [Page 8] NTLP Considerations and Implementation May 2004 R1 R2 R3 R4 +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | | | |+----+| ||NSLP|| | | | | ||NSLP|| |+----+| | | | | |+----+| |+----+| | | | | |+----+| ||NTLP||===>| |===>| |===>||NTLP|| |+----+| | | | | |+----+| +------+ +------+ +------+ +------+ ^ ^ | | (-->: Established state) (==>: Message direction) Figure 2: State establishment in case of SM=0 In the figure above, the message is sent by R1 to R4. The intermediate NE (NSIS Entity) can examine the NTLP message; however no state is established on intermediate nodes (i.e. R2, R3). SM=0 is used to directly establish states on two nodes. For example: an ingress router can send a signaling message with SM=0 directly to the egress node to establish states for a specific flow. 3.1.2 SM=1 In case of SM=1, the NTLP state is established on all NEs nodes along the data path regardless of NSLP applications. R1 R2 R3 R4 +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | | | |+----+| ||NSLP|| | | | | ||NSLP|| |+----+| | | | | |+----+| |+----+| |+----+| |+----+| |+----+| ====>||NTLP||===>||NTLP||===>||NTLP||===>||NTLP||===> |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ ^ ^ ^ ^ | | | | (-->: Established state) (==>: Message direction) Figure 3: State establishment in case of SM=1 In the figure above, the message is sent by R1 to R4. The Luu et al. [Page 9] NTLP Considerations and Implementation May 2004 intermediate NEs (NSIS Entity) examine the NTLP message and the state is established on intermediate nodes if the state is not established yet. The SM=1 is only used for the application requiring the signaling path must be seriously tied to the data path (e.g. resource reservation). When NTLP nodes establish states for a NSLP that they do not support (e.g. R2, R3 do not support NSLP1), the nodes register the content of message and sends it if there is a routing change. The NSLP content is opaque to NTLP. 3.1.3 SM=2 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, it will 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. R1 R2 R3 R4 +-------+ +-------+ +-------+ +-------+ | NE | | NE | | NE | | NE | |+-----+| |+-----+| | | |+-----+| ||NSLP1|| ||NSLP1|| | | ||NSLP1|| |+-----+| ||NSLP2|| | | |+-----+| | | |+-----+| | | | | | | | | | | | | |+-----+| |+-----+| |+-----+| |+-----+| ====>||NTLP ||===>||NTLP ||==..=>||NTLP ||=..==>||NTLP ||===> |+-----+| |+-----+| |+-----+| |+-----+| +-------+ +-------+ +------+ +-------+ ^ ^ ^ | | | (-->: Established state) (==> : Message direction) Figure 4: State establishment in case of SM=2 The SM=2 can be used for signaling applications which are not sensitive to routing changes as NAT/FW [Sti03]. In the figure above, the message is sent by R1 towards R4. The intermediate nodes R1, R2 and R3 support NSLP1, and the state is established on these nodes. Supposing that NSLP1 is the NAT/FW6_NSLP; R1 and R2 are the NAT/FW_NSLP aware nodes in the private domain of NI; R4 is the NAT/FW nodes in the private domain of NR. Therefore, the state should not be established on intermediate unaware-NAT/FW_NSLP nodes. The routing changes on nodes between two domains do not heavily influence the NAT/FW_NSLP application. 3.1.4 SM=3 The case of SM=3 looks like SM=2. However, if the state is not yet established, NTLP MUST wait the decision of NSLP to know whether the Luu et al. [Page 10] NTLP Considerations and Implementation May 2004 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. R1 R2 R3 R4 (edge) (interior) (interior) (edge) +-------+ +-------+ +-------+ +-------+ | NE | | NE | | NE | | NE | |+-----+| |+-----+| |+-----+| |+-----+| ||NSLP1|| ||NSLP1|| ||NSLP1|| ||NSLP1|| |+-----+| |+-----+| |+-----+| |+-----+| | | | | | | | | |+-----+| |+-----+| |+-----+| |+-----+| ====>||NTLP ||===>||NTLP ||===>||NTLP ||===>||NTLP ||===> |+-----+| |+-----+| |+-----+| |+-----+| +-------+ +-------+ +-------+ +-------+ ^ ^ | | (-->: Established state) (==> : Message direction) Figure 5: State establishment in case of SM=3 The case SM=3 can be used for any generic application. NSLP can decide if the NTLP must establish the state or not. The SM=3 can be used for signaling application such as that NTLP cannot decide if the state is established or not. For example, in the model RMD_QoS [Bad04], the ingress router (R1) sends signaling messages towards the egress router (R4). The messages are intercepted by all intermediate nodes, however, NSLP1 will decide if NTLP has to establish states for the (e.g. NSLP knows the state must be established because it is an edge node). 3.1.5 SM=4 In case of SM=4, the message is not involved in state establishment. It is used by NTLP to exchange the information of states which have been established (refresh, delete states) or other information (congestion control, security control...). 3.2 Messages Three types of message are defined in this document: New, Mod and Info message. 3.2.1 New message A New message is used to establish a new forward state for a signaling session between two signaling entities as follows: Luu et al. [Page 11] NTLP Considerations and Implementation May 2004 New ---> New R2 R3 New New --> +---+ +---+ ---> New ---> / ----| |--| |---- ---> Sender A R1 / +---+ +---+ \ R6 Receiver B +---+ +---+ / \ +---+ +---+ | |-----| |--- R4 R5 --| |--| | +---+ +---+ \ +---+ +---+ / +---+ +---+ NI \--| |---| |------ NR +---+ +---+ Figure 6: The New message path The signaling entity, which wants to initiate a signaling session, will send a New message along the data downstream path towards the other. New messages can be sent with the Router Alert IP option (RAO) in their IP headers to allow the NTLP on intermediates nodes to examine New messages. When processing a New message, NTLP nodes establish or do not establish state for the session. This is based on SM field in the message header. Since this message is used once for a session, NTLP must not verify if the state has been established or not. For bi-directional signaling applications, two New messages can be used to trigger the same bidirectional session if each of two ends (NI and NR) triggers an independent session from an one to the other. Otherwise, the NI sends a New message towards NR and then NR must send Mod message to establish the reserve session towards NI. 3.2.2 Mod message If this message is sent following the direction of the data path, this message is used to modify, refresh an established forward session on the current path or to establish a forward state on a new path (route change detection) as shown in the figure: Luu et al. [Page 12] NTLP Considerations and Implementation May 2004 Old route ---------------------------- / R2 R3 \ / +---+ +---+ ---> \ --- / ----| |--| |--- ---> Sender A R1 / +---+ +---+ \ R6 Receiver B +---+ +---+ / \ +---+ +---+ | |-----| |--- R4 R5 --| |--| | +---+ +---+ \ +---+ +---+ / +---+ +---+ NI \--| |---| |------ NR --> +---+ +---+ Mod Mod Mod ---> ----> / \ / ----------------------------> New route Figure 7: The Mod message along the downstream path This message is sent by the sender or sent by an intermediate NSIS-aware node. When a sender (NI) wants to modify an established session, it will send this Mod message toward the receiver to modify the established state on the data path. This message can be sent by an intermediate node (R1) to an end host. When a node detects a routing change, it MUST send a Mod message to the receiver on the new path. We suppose that a session is established on the R1, R2, R3, R6 and receiver B. If the sender A wants to modify this established session, it will send a Mod to the receiver. When there is no routing change, the Mod follows the route through R1, R2, R3 and R6 to the receiver B. The message can be sent by R1 when it detects a routing change. In this case, R4 will receive the Mod message. Since there is no state of this session previously established on R4, a new state of this session will be established on R4. Therefore, when a node receives Mod message, it must verify whether the state was established before. When R6 receives the message from R5, it can know there was a routing change by comparing the previous hop in this message and the previous hop of the established state. Note that the NI and NR can be the data sender in case of bidirectional signaling applications. If the routes are symmetric on some path segments of the data path (for example: symmetric at the AS level) and a signaling application wants to make use of it, Mod message MUST be used to initiate the reverse session on the data path from NR to NI. NTLP will examine if the session indicated in the message has been established following the opposite path or not. 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 on the data path as the figure below: Luu et al. [Page 13] NTLP Considerations and Implementation May 2004 Mod <<--- Mod New Mod Mod Mod <<--- ---> <<--- <<--- <<--- New R3 R4 New New New --> +----+ +----+ ---> ---> ---> / ---| |---| |--- NI R1 R2 / +----+ +----+ \ NR +----+ +----+ +----+ / \ +----+ | |----| |-----| |--- R5 R6 ---| | +----+ +----+ +----+ \ +----+ +----+ / +----+ Sender \--| |---| |--- Receiver +----+ +----+ Figure 8: The Mod message along the upstream path 3.2.3 Info message The Info message is not used to established states on the data path. It is only used to exchange the information between two NTLP peers, between two NSLP peers (regardless of intermediate non-NSLP aware NEs) or between NI and NR. The exchanged information can be: Acknowledge a message, refresh a state, delete a state and other information for security and overload control purposes. 3.3 Refresh mechanism [Pan97] introduced a staged refresh timer mechanism. The staged refresh timer mechanism retransmits RSVP messages until the receiving node acknowledges to change the value of timer. However, it is complicate to maintain on per-session timer maintenance. In the document, we propose a simple mechanism to reduce the refresh payload in the message and retake the benefit from [Pan97]. Each node has a socket list to the next node and a socket list to the previous node along the data path. A socket list contains the entries which is the SESSION_ID values of established sessions or is empty (null). R1 R2 Socket list 1 +----+ +----+ Socket list 1 R1 to R2 | |-------------------------| | R1 to R2 of R1 +----+ +----+ of R2 +-----------+ trigger message (New or Mod) +----------------+ |00: empty | (SESSION_ID=A ) |00: SESSION_ID=A| |01: empty | -------------------------> |01: empty | |.. . . . | |. . . . | |xx: empty | ACK of trigger message in case |xx: empty | +-----------+ the state is established +----------------+ (downstream (SESSION_ID=A, SOCKET_ID=N) (upstream to R2) to R1) <------------------------- . Luu et al. [Page 14] NTLP Considerations and Implementation May 2004 . Refresh (SOCKET_ID=0->10, 50->100...) -------------------------> Figure 9: Refresh reduction mechanism We suppose that the state will be established on the node R2 after it receives the New (or Mod) message from R1. At first, the socket list of each peer contains empty socket entries (null). When R2 establishes the state, it searches the first null socket and sends back this value (socket-id) to R1. Because the first null socket entry is 00, this value is 00 for session A (SESSION_ID=A). Node R1 will register this value in its socket list corresponding to R2. If there are other established sessions, the socket list will be gradually filled. To refresh the socket list 1, R1 sends a REFRESH object to R2. This REFRESH object contains the socket_ids corresponding to established sessions from R1 to R2. Instead of containing all non null socket-id, the object only contains the blocks of socket_id. A block is seamless sequence of non null socket_ids value. Each block is defined by the start socket_id and the number of non null socket_ids in that block. There can be more than one socket list between two signaling entities. These lists can be categorized following the time out interval for signaling applications and the idea of staged refresh timer [Pan97] can be reused. The NTLP does not try to orient to per flow session refresh. When a list is refresh, all established sessions in that list is refreshed. 3.4 Reliable message delivery In this proposal, NTLP supports the reliable message delivery Service for NSLP. Transmission is made reliable via the use of sequence numbers and acknowledgments. A NE can explicitly know its NTLP messages are received by another NE. The NSLP messages can be carried by many objects (see 4.4.7 to 4.4.11). Some requires the reliable transport; the others do not require it. In case the reliable delivery is required, the NTLP sets the bit ACK of the objects and send it in a message. When receiving this message, the NTLP must send back an acknowledgement. Each object is identified globally by SESSION_ID and the sequential number. Note that the sequential number is only meaningful for a session in the peer to peer scope. This number is only used for acknowledgements and it is not used for packet lost detection. This number is increasingly changed for any NSLP message of the same SESSION_ID. Luu et al. [Page 15] NTLP Considerations and Implementation May 2004 R1 R2 +----+ +----+ | |------------------| | +----+ +----+ message (...(SESSION_ID=A, Num=0)) ------------------> ACK (...(SESSION_ID=A, Num=0)) <----------------- message (...(SESSION_ID=A, Num=1)) ------------------> ACK (...(SESSION_ID=A, Num=1)) <----------------- In the figure, we suppose that the state will be established on R2. At first, R1 sends a NSLP message transported in an NTLP object. The NSLP message belongs to the session identified by SESSION_ID=A. The first message is sent with sequence number 0. R2 will send back an ACK to acknowledge the reception. If R1 sends another message of the same session, the sequence number must be more than 0 (e.g. 1). If this message is lost, R1 will resend the message with the sequential number 2. A NTLP message can carry many objects. It is not necessary to receive all ACKs of each object in a message to decide these objects were received. The objects in a message are known to be received if only one among these object are acknowledged. This will reduce the signaling payload of reception acknowledgement. 3.5 Security protection In the document, the INTEGRITY class of RSVP (RFC2747)[Bar00] is reused to authenticate messages and to protect the NTLP from replay attacks. The document reuses the security protection. The part 6 gives more security consideration. However, this will be analyzed more in detail in the next version of the draft. 3.6 Path MTU discovery and fragmentation In the document, a simple mechanism is proposed to detect the MTU to the next NSIS nodes (Path MTU). R1 R1 R2 R4 +---+ +---+ +---+ +---+ --| |---...-| |-----...---| |---...---| |--- +---+ +---+ +---+ +---+ Trigger Trigger Trigger (New or Mod) -----> -----> --X--> (message is dropped ) Info(Detect) Info(Detect) Info(Detect) Luu et al. [Page 16] NTLP Considerations and Implementation May 2004 -----> -----> -----> Info(MTU) Info(MTU) Info(MTU) <----- <----- <----- Figure 10: Path MTU discovery mechanism We assume that NSLP needs to send a message from R1 toward the receiver along the data path (figure 5) and the NTLP state is not established before (e.g. a new session, route change). If the message length is larger than 576 (for IPv4) or larger than 1280 (for IPv6), the NTLP must send the New (or Mod) message following an Info message respectively. Note that 576/1280 is the minimum of acceptable MTU values in the IPv4/IPv6 network. The Info message only carries the information about R1 and session-id to ensure this message will not be drop due to its length which is larger than path MTU. We call this message Info Detect. Supposing the state will be establish on R4. If R4 only receives the Info message and the New (or Mod) message was dropped, it continues waiting a short time before sending back a notification of packet lost. The notification can be transported in an other Info message. This message also informs the link MTU of the interface through which the Info Detect message is received. When R1 receives the Info message from R4, it knows the next NSIS aware node is R4 and the link MTU of the interface through which the R4 received the message. Now R1 can use Path MTU discovery mechanisms for IP packet [Mog90] [McC96] with the first path MTU value which is the minimum of the path MTU of R1 and the link MTU received from R4. 4. NSIS Transport Layer Protocol Specification In this document, the NTLP is designed to run directly on the IP layer or on UDP. 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. 4.1. Common header Luu et al. [Page 17] NTLP Considerations and Implementation May 2004 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. The New message is used to establish NTLP states in nodes along the data path. M_Type = 2 : Message type is Mod. The message is used to reestablish NTLP states on a new data path. It is also used to establish NTLP states on the nodes along the reverse data path. M_Type = 3 : Message type is Info. The message is used to support the state management (refreshing, deleting state) and exchange information (e.g. error notification) between NTLP aware nodes. Flag : 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | SM | (Resv)| +-+-+-+-+-+-+-+-+ SM: State management (4 bits). SM indicates where a state is established along the data path for any generic signaling application. By using different SM values, the time for examine the signaling messages is optimized by avoiding examining a whole message. SM=0: SM=0 is used for directly sending signaling message between two NEs without interference of intermediate nodes. This message can be sent with a RAO in the IP header. In this case, the message is examined by intermediate nodes to ensure the hop by hop security and then the message is forwarded without establishing state. SM=1: This message is always sent with a RAO in the IP Luu et al. [Page 18] NTLP Considerations and Implementation May 2004 header. 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 the session. SM=1 can be used for the signaling applications which need to establish state on all NTLP-aware nodes on the signaling path. SM=2: This message is always sent with a RAO in the IP header. If an intermediate node supporting a specific NSLP indicated in the message receives, the 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 signaling applications that only need to establish state on NSLP-aware nodes. SM=3: This message is always sent with a RAO in the IP header. If an intermediate node supporting the NSLP indicated in the 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 NSLP-aware, NTLP MUST not examine the entire message. It can check the Integrity object to assure the hop by hop security. SM=4: The message with SM=4 does not contain the objects to establish a state. It only carries the information to support the state management (refreshing, deleting state) and exchanges of information (e.g. error notification) between NTLP aware nodes. (Resv): 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. It is used to detect if message is correctly received. In case there are some other mechanism to do it (e.g. integrity protection), the checksum can be omitted. 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 Luu et al. [Page 19] NTLP Considerations and Implementation May 2004 The total length of this NTLP message in bytes, including the common header and the variable-length objects that follow. This is used for the message boundary delineation. 4.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) // | | +-------------+-------------+-------------+-------------+ 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 address of the NSIS-aware node that sends this message. An IP_HOP object will indicate the PHOP ("previous hop") address for downstream messages or as the NHOP ("next hop") address 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" for a bi-directional signaling application and they do not need to be the same. Luu et al. [Page 20] NTLP Considerations and Implementation May 2004 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. The refresh period is independent to refresh mechanisms (e.g. refreshing by sending the original message following the data path, refreshing by sending message directly between NSIS aware nodes. 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). INTEGRITY Carries cryptographic data to authenticate the Originating node and to verify the contents of the NTLP message. LINK_MTU_S Carries the MTU of the interface through which the signaling message is sent. LINK_MTU_R Carries the MTU of the interface through which the signaling message is received. SESSION_FULL_MSG Transport the NSLP messages of a signaling session. Each message is identified by the SESSION_ID, the NSLP_ID and the sequential number of session. SESSION Carries the SESSION_ID of the session. SESSION_TEAR Carries the deletion request of an established state. SESSION_ERROR Carries errors concerning a session. SESSION_ACK Carries the acknowledgement of an object. Luu et al. [Page 21] NTLP Considerations and Implementation May 2004 SESSION_REFRESH Carries the refreshment of established sessions. SESSION_FMR (Full Message Required) When a NE receives a SESSION_REFRESH class object of a state which has not been established, NE uses this object to require a full message to establish a new state. SESSION_FRAGMENT Carries fragments of a fragmented NSLP message in the case the message?s length is larger than the path MTU. NSLP_INFO Carries the information exchanged between NSLPs of the same specific NSLP application. The information can be about overload control, topology information... This information is opaque to NTLP layer and does not concern with any specific 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. 4.3. NTLP message The format of NTLP message is as follows: :: = [][*] [][] [][] [SESSION_FULL_MSG>*][SESSION_FRAGMENT>*] [SESSION_REFRESH>*][SESSION_ACK>*][*] [*][*] [*][*] (The "*" denotes one or more than one object) If the INTEGRITY is present, it SHOULD immediately follow common header. The SESSION SHOULD be placed after the FLOW_ID object. An Luu et al. [Page 22] NTLP Considerations and Implementation May 2004 implementation should create messages with the objects in the order shown here, but accept the objects in any permissible order. If the LINK_MTU_S is present, it indicates the minimum value of the link MTU of the interface through which the message was sent and the one through which the message will be sent. If the LINK_MTU_R is present, it indicates the link MTU of the interface through which the message was received. There can be two IP_HOP objects in a NTLP message. In case SM=1, the state can be established on non-NSLP-aware node. One IP-HOP object identifies the NSLP-aware node, and the other node identifies the node sends this message (see the next part). 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_FULL_MSG, SESSION_REFRESH, SESSION_ACK, SESSION_ERROR class object in a NTLP message. The objects transport NSLP messages. 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 link MTU. 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. 4.3.1. New message The message is sent end to end, initiated by NI and terminate by NR (possibly by other intermediate signaling entities). A New message is used once for a session. When a node receives a New message, it knows that the session indicated is a new one and node must not verify if this state was established before. For bi-directional signaling applications, if each end initiates an session which is independent of each other, two New messages will be used to establish two session. If two sessions are dependent, the NI sends a New message to established the session from NI to NR. NR sends the Mod message established the session from NR to NI. 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 Luu et al. [Page 23] NTLP Considerations and Implementation May 2004 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. The format of a New message is as follows: ::=[][*][] [] [*][] In case the message has SM=0 and an RAO in the IP header, 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 (see the next part). 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 11: 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 the figure above. 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 object (IP address=R1). Because SM=2 (or 3), no state is established on the NSLP1-unaware node R2 (IP_HOP REMOTE). R2 puts 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 Luu et al. [Page 24] NTLP Considerations and Implementation May 2004 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 4.4.7). 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. LINK_MTU_S carries the link MTU value of the interface through which the messages is sent . 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 a 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 since the state has been established by the New message. 4.3.2 Mod message This message can be sent along the data path or along the reverse data path. If this message is sent along 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 (in case the route changes). 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 4.4.7) on the data path. 4.3.2.1. Mod message in the direction of data path In this section, we describe a Mod message which follows the Luu et al. [Page 25] NTLP Considerations and Implementation May 2004 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 data sender can be NI or NR. In case of bi-directional 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 somewhere in the network. 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. 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. 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. 4.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 to avoid the interception of intermediate nodes on the opposite direction of data path. 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 26] NTLP Considerations and Implementation May 2004 ::=[][] [][] [] * [*][*] [*][*] [*][*] [*][*] 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. LINK_MTU_S carries the link MTU value of the interface through which the messages is sent . LINK_MTU_R carries the link MTU value of the interface through which the messages from the upstream nodes were received. 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. 4.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: The Info message will transport SESSION_ACK objects for the Luu et al. [Page 27] NTLP Considerations and Implementation May 2004 acknowledgements. - 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. In 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. In case the route changes, this is used to delete only the established state on nodes between two cross routers (the router on the old and new data path) but the whole 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). The message can be sent directly between two end host without interpretation of the intermediate nodes. - End to end : This addressing is used when the entity that sends the message does not know the address of the next hop which establishes the state. 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. If SM=0, the FLOW_ID can be not present in the messages. * In the peer to peer addressing case, the format of an INFO message is as follows: Luu et al. [Page 28] NTLP Considerations and Implementation May 2004 ::=[][] [*] [][] [*][*] [*][*] [*][*] The message MUST be sent with SM=4. 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 end to end addressing case, the format of an INFO message is as follows: ::=[][] [] [*][*] [][*] FLOW_ID object MUST be present in this message for routing. LINK_MTU_S is the link MTU of the interface through which the message is sent. There can be SESSION_REFRESH objects, SESSION_TEAR objects, NSLP_INFO objects. These objects MUST be sent to the same destination. 4.4. NTLP objects 4.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)| | +-------------+-------------+ + Luu et al. [Page 29] NTLP Considerations and Implementation May 2004 | Key Identifier | +-------------+-------------+-------------+-------------+ | Sequence Number | | | +-------------+-------------+-------------+-------------+ | | + + | | + Keyed Message Digest | | | + + | | +-------------+-------------+-------------+-------------+ The fields of this object are defined in [Bar00] 4.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) + | | + + | | Luu et al. [Page 30] NTLP Considerations and Implementation May 2004 +-------------+-------------+-------------+-------------+ 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) + | | + + | | + + | | +-------------+-------------+-------------+-------------+ 4.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. 4.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 Luu et al. [Page 31] NTLP Considerations and Implementation May 2004 +---------------+---------------+---------------+--------------+ | IPv4 SrcAddress | +---------------+---------------+---------------+--------------+ | IPv4 DestAddress | +---------------+---------------+---------------+--------------+ | SPI | +---------------+---------------+---------------+--------------+ | Protocol Id | // | +---------------+---------------+---------------+--------------+ o IPv6 FLOW_ID Object: Class = 4, C-Type = 3 +---------------+---------------+---------------+--------------+ | | + + | IPv6 SrcAddress (16 bytes) | + + | | + + | | +---------------+---------------+---------------+--------------+ | | + + | IPv6 DestAddress (16bytes) | + + | | + + | | +---------------+---------------+---------------+--------------+ | // | Flow Label (20 bits) | +---------------+---------------+---------------+--------------+ 4.4.5. LINK_MTU_S LINK_MTU_S class = 5 o LINK_MTU_S : Class=5, C-type=1 +---------------+---------------+---------------+--------------+ | (Reserve) | Link_MTU value (16 bits) | +---------------+---------------+---------------+--------------+ Link_MTU_S is the value of MTU through which the message is sent. 4.4.6. LINK_MTU_R LINK_MTU_R class = 6 o LINK_MTU_R : Class=6, C-type=1 Luu et al. [Page 32] NTLP Considerations and Implementation May 2004 +---------------+---------------+---------------+--------------+ | (Reserve) | Link_MTU value (16 bits) | +---------------+---------------+---------------+--------------+ Link_MTU_R is the value of MTU through which the messages are received from the upstream hop. 4.4.7 SESSION class SESSION class=7 o SESSION : Class=7, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_type | (Reserved) | NSLP_ID | Attr-Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag: 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A| | |C| (Reserved) | |K| | +-+-+-+-+-+-+-+-+ ACK: Acknowledge If the entity sending this message wants to receive the acknowledge of this message, this bit will be set Message sequence: This the message sequence for only one session indicated in the object. Every time the node (where state is established here) sends an object of this type of a specific session, this number will increasingly change. Luu et al. [Page 33] NTLP Considerations and Implementation May 2004 Sesssion_Type: This defines the types of SESSION_ID. In this version, this value is only 1. NSLP_ID: identification of a specific NSLP Attribute flag (Attr-Flag): 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | | |H|D| | | |D|B|T|F| | | | | | | | | | +-+-+-+-+-+-+-+-+ 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 34] NTLP Considerations and Implementation May 2004 DF: Don't fragment If this bit is set, the SESSION full message object must be not fragmented by NTLP. 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 MAC Address: MAC Address of the host that initiates this message. It can be randomly created. 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. 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. However, which entity (NI, NR or a third party) create MAC address, Random (NSLP session) is out of scope of this document. 4.4.8 SESSION_FULL_MSG class SESSION_FULL_MSG class=8 o SESSION_FULL_MSG: Class=8, C-type=1 This object is used to identify globally a session of a signaling application and transport the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr-Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luu et al. [Page 35] NTLP Considerations and Implementation May 2004 | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // NSLP Message contents // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag: 8 bit 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A| | |C| (Reserved) | |K| | +-+-+-+-+-+-+-+-+ ACK: Acknowledge If the entity sending this message wants to receive the acknowledge of this message, this bit will be set Message sequence: This the message sequence for only one session indicated in the object. Every time the node (where state is established here) sends a message of this session, this number will increasingly change. Sesssion_Type, NSLP_ID, Attr-Flag, Ramdom number, MAC, State sequential number: see 4.4.7 NSLP Message contents : This is the content of NSLP message and it is opaque to NTLP. 4.4.9 SESSION_TEAR class SESSION_FULL_MSG class=9 This object is used to delete an established session. o SESSION_TEAR: Class=9, C-type=1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | Luu et al. [Page 36] NTLP Considerations and Implementation May 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag, Message sequence, Session_Type, NSLP_ID, Attr_Flag, Random number, MAC, State sequence number (see 4.4.8). 4.4.10 SESSION_FMR (Full Message Required) class SESSION_FMR (Full Message Required) class=10, C-type=1 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. o SESSION_FMR: Class=9, C-type=1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Session_Type, NSLP_ID, Attr_Flag, Random number, MAC, State sequence number as 4.4.8). 4.4.11 SESSION_ERROR class SESSION_ERROR class=11, C-type=1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luu et al. [Page 37] NTLP Considerations and Implementation May 2004 | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/+ | | // Error of the signaling application session // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/+ Flag, Message sequence number, Sesssion_Type, NSLP_ID, Attr-Flag, Ramdom number, MAC, State sequential number: see 4.4.7 Error of the signaling application session: this is the content of error NSLP message and it is opaque to NTLP. 4.4.12 SESSION_ACK class o SESSION_ACK class=12, C-type=1 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) | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message sequence number, Sesssion_Type, NSLP_ID, Attr-Flag, Ramdom number, MAC, State sequential number: see 4.4.7 o SESSION_ACK_SOCKETID class=12, C-type=2 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) | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List_ID | Socket_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luu et al. [Page 38] NTLP Considerations and Implementation May 2004 Message sequence number, Sesssion_Type, NSLP_ID, Attr-Flag, Ramdom number, MAC, State sequential number: see 4.4.7 List_ID: The identifier of the list (see 3.3). Socket_ID: The first socket position in the list that is empty (null) (see 3.3). o SESSION_ACK_SOCKET_REDUCE class=12, C-type=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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List_ID | Socket_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Reserved) | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message sequence: see 4.4.7 4.4.13 SESSION_REFRESH class o SESSION_REFRESH class=13, C-type=1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o SESSION_REFRESH_LIST class=14, C-type=2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List_ID | Number of socket full block=M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Reserved) | Non null socket id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block 1 start | block 1 end | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Luu et al. [Page 39] NTLP Considerations and Implementation May 2004 // . . . // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block M start | length of block M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K (2^16*K) | Number of socket full block= N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block 1 start | block 1 end | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block N start | length of block N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Number of socket full block: the number of Socket-ID seamless interval. In each Socket interval, there is not any gaps. For example : Socket list 1 +--------------+ |00: Session X | | (Non-null socket 00 is chosen) |01: Session Y | | block 1 (start=00, length=03) |02: Session B | | |03: empty | = gap |04: Session K | | block 2 (start 02 (04-02=02), end=01) |05: empty | = gap | . . . | +--------------+ Non null socket id: The first Socket_ID is not empty (null). block 1 start: 0 length of block 1: the number of block seamless Socket_ID Because the length is less than 2^16, if there is a number of seamless null Socket_ID is more than 2^16 from the block N, the object will calculate K, the entire maximum number times of 2^16 that 2^16*K < the number of seamless null Socket_ID. 4.4.14 SESSION_FRAGMENT class SESSION_FRAGMENT class o SESSION_FRAGMENT class=14, C-type=1 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) |Num of fragment |Fragment Num | Luu et al. [Page 40] NTLP Considerations and Implementation May 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Message sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_Type | (Reserved) | NSLP_ID | Attr_Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+ | Random number (NSLP session) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/+ | MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | State sequential number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/+ | | / Fragment of NSLP Message contents + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/+ Num of Fragment: number of fragments of the NSLP message. Fragment Num: sequential number of fragment. This field indicates where in the SESSION_FULL_MSG object this fragment belongs to. Fragment of NSLP Message contents: the fragment of fragmented NSLP message content of the SESSION_FULL_MSG object. 4.4.15 NSLP_INFO class NSLP_INFO class=15 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. 4.4.16 NTLP_INFO class NTLP_INFO class=16 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 5. 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. 5.1. Using NTLP for resource reservation in IntServ environment Luu et al. [Page 41] NTLP Considerations and Implementation May 2004 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. 5.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 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 (in the figure below). 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 12: The simple schema for illustrating NSLP_QoS_R 5.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): Luu et al. [Page 42] NTLP Considerations and Implementation May 2004 ::= [] [] [*] [] 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 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. 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 fragments are carried in SESSION_FRAGMENT object in Mod messages. 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). Luu et al. [Page 43] NTLP Considerations and Implementation May 2004 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. 5.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 44] NTLP Considerations and Implementation May 2004 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. 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). 5.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 Luu et al. [Page 45] NTLP Considerations and Implementation May 2004 the backward state has not established yet (e.g. The receiver (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 and the SM of the Info message must be copied from the trigger message (New or Mod). 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 4. 5.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. 5.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 5.1.1.1 5.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 5.1.1.3 5.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 towards receiver. 5.1.2.4. Bi-directional reservation Luu et al. [Page 46] NTLP Considerations and Implementation May 2004 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. 5.2. NTLP for Middlebox configuration In this section, we use the messages of [Tsc03a] to signal information to firewall and NAT. We call signaling application for Midcom NSLP_Midcom. We do not analyze [Tsc03a], this is only an example to show how the proposed NTLP can support Middlebox configuration. The messages of [Tsc03a] 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. 5.2.1. Path message Message Path is placed in the message New of NTLP. The format of the message NEW: ::= [] [] [*] [] Luu et al. [Page 47] NTLP Considerations and Implementation May 2004 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 fragments are carried in SESSION_FRAGMENT object in Mod messages. 5.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 5.2.1. If the Create message is used in mode receiver-initiated, it Luu et al. [Page 48] NTLP Considerations and Implementation May 2004 must be placed in Mod message. Mod message that transports Create is the same as the Mod message in 5.1.1.2. 5.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. 5.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. 5.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. 5.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 NSLP_Midcom aware intermediate node to an end host. The SM of common header of this message must be 0. 6. 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. -Entity Authentication & Integrity: Corrupted or spoofed NTLP messages could lead to theft of service by unauthorized parties or to denial of service caused by locking up network resources. NTLP protects against such attacks with a hop-by-hop authentication mechanism using an encrypted hash Luu et al. [Page 49] NTLP Considerations and Implementation May 2004 function. -Anti-replay: NTLP protects against replay attacks with a hop-by-hop sequence number mechanism. This sequence number is 64 bits in length. In order for the receiver to distinguish between a new and a replayed message, the sequence number must be monotonically incremented modulo 2^64 for each message. The authentication and anti-replay mechanisms are supported by an INTEGRITY object that may appear in any NTLP message. Even with an INTEGRITY object, NTLP still raises some security issues. Here are some of them. o Dynamic Key Management for SA establishment The INTEGRITY object use a keyed cryptographic digest technique, which assumes that NTLP neighbors share a secret. Widespread use of the NTLP integrity mechanism will require the availability of the long-sought key management and distribution infrastructure for routers. Until that infrastructure becomes available, manual key management will be required to secure NTLP message integrity. [Tsc03b] proposes the usage of the ISAKMP protocol with a new Domain of Interpretation (DoI) and allows to establish the necessary security parameters for the RSVP Integrity object. The RSVP Integrity object uses this DoI to dynamically establish the necessary security associations. As far as we are concerned, this is of prime interest to watch the evolutions of [Tsc03]. We should apply the results to the dynamic key management of the NTLP integrity object. o User authentication / Authorization User authentication is not addressed in this version of NTLP. However, this is the work of NSLP rather NTLP. As noted in [Tsc03c], using RSVP, a user (or an application) may authenticate to the first hop router or to the PDP. [RFC3182] describes how user and application information is embedded into the RSVP message (AUTH_DATA object in the POLICY_DATA object) and how to protect it. User-based authorization is performed with the POLICY_DATA object providing user credentials. The inclusion of user and application specific information enables policy-based control with special user policies that are likely to be stored at a dedicated server. Luu et al. [Page 50] NTLP Considerations and Implementation May 2004 In this version of NTLP, neither user authentication, nor the authorization with policy-based control is supported. o Analysis for DoS attacks: DoS attacks are typically used to take important servers out of action. It can also be used to interrupt the services of routers. This part aims at giving some threats that lead to the misfunctioning/interruption of the NTLP/NSLP services on a NSIS node. When an intermediate NSIS node receives a NTLP message with SM=1, NTLP MUST entirely examine the message. If the state is not yet established, it must establish a state for this new session. Let us consider an attacker who generates an overwhelming amount of dummy NTLP messages with SM=1. The next NSIS node will have to examine all this amount of traffic, establish a state or generate an error message. All this unnecessary processing will consume resources to finally lead to an efficient DoS attack. Upon reception of a NTLP message with SM=1, a NSIS node should be able to check the validity of the message before processing and forwarding it. A control procedure should be available to process or drop NTLP messages with SM=1. Any NSIS node, even without NSLP installed, should be able to contact a third party (eg. PDP) to authorize a NTLP message with SM=1. In peer-to-first hop or inter-domain communications, the edge node(s) must control NTLP messages with SM=1. In intra-domain communications where a trust relationship likely exist between internal NSIS nodes, we can omit such a control. The reduction of processing load on the internal NSIS nodes could be significant. 7. 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 Luu et al. [Page 51] NTLP Considerations and Implementation May 2004 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. A refresh reduction mechanism is presented in the document with the socket notion. Two states 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. Reference [Bru03] M. Brunner, "Requirements for Signaling Protocols", work in progress, draft-ietf-nsis-req-09.txt, August 2003 [Han03] R. Hancock et al, "Next Step in Signaling: Framework", work in progress, draft-ietf-nsis-fw-02.txt, May 2003. [Ham03] L-N Hamer et al., " Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. [Bad04] A. Bader et al.,"RMD (Resource Management in Diffserv) QoS-NSLP model", Internet Draft, Work in progress, draft-bader-RMD-QoS-model-00, February 2004 [Bar00] F. Barker et al., RSVP Cryptographic Authentification, RFC 2747, January 2000 [Ber01] L. Berger et al, "RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001. [Bra97] R. Braden et al, "Resource Reservation protocol" Version 1 Functional Specification RSVP, RFC2205, September 1997 [Bou03] N. Boukhatem, N. et al, "IP Signaling: Requirements", livrable of IPSIG project, May 2003 [Kat97] D. Katz, "IP Router Alert Option", RFC2113, February 1997 [Mog90] J. Mogulet al., Path MTU Discovery, November 1990 [McC96] J. McCann et al., Path MTU Discovery for IP version 6, August Luu et al. [Page 52] NTLP Considerations and Implementation May 2004 1996 [Sch03] H. Schulzrinne, et al, "CASP - Cross-Application Signaling Protocol", Internet Draft, work in progress, draft-schulzrinne-nsis-casp-01.txt, May 2003 [Sho03] M. Shore, "The NSIS Transport Layer Protocol (NTLP)", draft-shore-ntlp-00.txt", Internet Draft, work in progress, May 2003 [Sti03] M. Stiemerling et al., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet draft, work in progress, draft-ietf-nsis-nslp-natfw-00, October 2003 [Par99] C. Partridge et al., IPv6 Router Alert Option, RFC 2711, October 1999 [Pan97] Ping Pan et al., "Staged refresh timers for RSVP", Global Telecommunications Conference, 1997. GLOBECOM '97., IEEE , Volume: 3 , 3-8 Nov. 1997 Pages:1909 - 1913 vol.3 [Sve03] Sven Van den Bosch et al., "NSLP for Quality-of-Service signaling", Internet Draft, work in progress, draft-ietf-nsis-qos-nslp-01.txt, October 2003 [Tsc03] H. Tschofenig et al., "Security Implications of the Session Identifier", Internet draft, work in progress, June 2003. [Tsc03a]H. Tschofenig et al,'A Firewall/NAT Traversal Client for CASP', work in progress, draft-tschofenig-nsis-casp-midcom-01.txt, May 2003 [Tsc03b]H. Tschofenig et al, 'RSVP Domain of Interpretation for ISAKMP', work in progress, draft-tschofenig-rsvp-doi-01.txt, October 2003 [Tsc03c]H. Tschofenig et al, 'RSVP Security Properties', work in progress, draft-ietf-nsis-rsvp-sec-properties-03.txt, October 2003 [Wan99] Lan Wang et al., "A New Proposal for RSVP Refreshes", (ICNP '99) Proceedings. Seventh International Conference on , Oct.31-Nov.3, 1999, Pages:163 - 172 [Wes03] L. Westberg et al, "A Proposal for RSVPv2-NSLP", Internet Draft work in progress, draft-westberg-proposal-for-rsvpv2-nslp-00.txt, April 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 Luu et al. [Page 53] NTLP Considerations and Implementation May 2004 always a pleasure to discuss the signalling problems with you. We would like to thank IPSIG members for their contributions in this draft. 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 54] NTLP Considerations and Implementation May 2004 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.