idnits 2.17.1 draft-buchli-nsis-ntlp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7620 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 15 looks like a reference -- Missing reference section? '2' on line 44 looks like a reference -- Missing reference section? '3' on line 59 looks like a reference -- Missing reference section? '4' on line 196 looks like a reference -- Missing reference section? '5' on line 71 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS working group 3 Internet Draft M. Buchli 4 E. Waegeman 5 S. Van den Bosch 6 Document: draft-buchli-nsis-ntlp-00.txt Alcatel 7 Expires: December 2003 June 2003 9 Implementation of CASP NTLP 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes the implementation of a signaling protocol 34 based on the two protocol layer concept of NSIS. The implementation 35 of the transport layer is based on the CASP proposal and is 36 discussed in this document. The design of a client layer for QoS 37 signaling is detailed in a separate document. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in RFC-2119 [2]. 45 Table of Contents 46 1. Terminology....................................................2 47 2. Introduction...................................................2 48 3. Transport layer................................................3 49 3.1 Route changes..............................................4 50 3.2 Interaction with client layer..............................4 51 3.3 Flow ID....................................................4 52 3.4 State management...........................................4 53 Security Considerations...........................................5 54 References........................................................5 55 Author's Addresses................................................6 57 1. Terminology 59 The terminology used in this document is aligned with [3]. 61 2. Introduction 63 We have implemented a signaling protocol according to the two-layer 64 protocol model of NSIS. It consists of a generic transport layer 65 (NTLP) and an application specific layer (NSLP). 67 The implemented NTLP is a modified version of the CASP transport 68 layer protocol as specified in [4]. The aim of this document is to 69 provide the design choices made for the NTLP protocol. The design of 70 the QoS signaling protocol that has been implemented is documented 71 separately in [5]. 73 The protocol layer model is depicted in figure 1. As depicted, 74 certain functionalities of the transport layer can be implemented by 75 existing (and proven) protocols to provide e.g. reliable delivery 76 and security. 78 +=========================================+ 79 | | 80 | Client layer (NSLP) | 81 | | 82 +=========================================+ 83 | | - 84 | Transport layer | \ 85 |.........................................| | 86 | [security protocols (IPSec, TLS)] | | NTLP 87 |.........................................| | 88 | transport protocol (TCP, SCTP) | / 89 +=========================================+ - 90 | IPv4, IPv6 | 91 +=========================================+ 92 Figure 1:Protocol layer model 94 As mentioned before, the transport layer is a modification of the 95 CASP proposal [4]. The main differences are: 97 o The transport layer only detects route changes and triggers the 98 NSLP. The NSLP is in full control of executing the required 99 actions upon the route change notification. 101 o Only one NSLP type can be associated to a transport session. 103 o Each node involved with a session should support the NSLP. Hence, 104 in case of a route change there is always an NSLP in place that 105 can react on the route change. Furthermore, much of the required 106 security functionality can be incorporated at the NTLP. 108 o The Flow ID is defined by the source and destination address. This 109 allows for multiple flows within a single session between two end 110 hosts. 112 o Only SCTP and TCP are considered as transport protocols in order 113 to provide reliable delivery, fragementation, congestion control, 114 etc. Hence, raw IP and UDP are not considered for transport. 116 3. Transport layer 118 The implementation of the transport layer is derived from the 119 specification of [4]. Some functionalities are not considered, are 120 specific to our usage scenario or will be implemented in a later 121 stage. 123 Not considered for implementation: 124 - In-band discovery by means of SCOUT messages. When, in a later 125 stage, dynamic discovery will be implemented a directory based 126 approach will be used. 128 Not required for our usage scenario: 129 - Currently, only a QoS signaling client layer is considered. Fate 130 sharing is assumed between the transport and client layer. The 131 soft state mechanism is located in the transport layer; the client 132 layer does not have a notion of refresh messages. 134 Functionality to be added in future versions: 135 - Security features, these may be provided by existing security 136 protocols such as IPSec. 137 - Dynamic discovery of neighbors; currently, the neighbor 138 information is configured statically. 140 The design choices for the transport layer protocol are elaborated 141 in some more detail below. 143 3.1 Route changes 145 o Route changes are detected by the transport layer but the actions 146 to respond to the route change and the removal of transport/client 147 state on the old path is the task of the client layer. Indeed, 148 this provides the client layer full control to implement 149 application specific actions to react to a route change; e.g. when 150 to release the state on the old path. 152 3.2 Interaction with client layer 154 o The number of client layers associated with a transport session is 155 restricted to one. This avoids the transport layer having to 156 determine when all client layers have finished the processing of a 157 route change before the transport layer may release the transport 158 state on the old path. By allowing only one client per session the 159 client layer has full control in case of a route change. 161 o When a session is setup each signaling node involved with that 162 session should support the particular client layer. This is 163 due to the following reasons: 165 - Route changes can be handled by the client layer at the node 166 where the route change was detected. It avoids the need for 167 signaling to an upstream signaling node, which supports the 168 specific client layer, to trigger the necessary actions for a 169 route change. 171 - Security and keep-alive mechanisms can be constraint to a hop- 172 by-hop scope, and hence, can be implemented at the transport 173 layer. However, objects that require e.g. end-to-end protection 174 may be protected at the client layer. 176 3.3 Flow ID 178 o The flow at the transport layer is only defined by the source and 179 destination IP address. The client layer may handle more 180 specific flow information, e.g. port numbers and protocol 181 identifier. This allows to support multiple flows within the same 182 session between two end hosts. 184 o At the client layer, multiple source/destination ports may be 185 specified for each session. 187 3.4 State management 188 o Soft state management is considered a generic functionality, and 189 hence, included in the transport layer. Only the transport state 190 is refreshed, not the client objects. In case the soft state times 191 out the transport layer will trigger the client layer. The client 192 layer is responsible for discarding the state. 194 In order to support soft state at the transport layer an 195 additional bit is defined in the common header as defined in 196 section 4.2 of [4]. Bit 4 of the flag field is designated as 197 the refresh bit. This bit is set to �1� to indicate a refresh 198 message; otherwise it should be set to �0�. 200 The refresh message has the refresh bit set and contains one or 201 more session ids that need to be refreshed. The number of sessions 202 to be refreshed can be derived from the message length. The 203 refresh interval between two neighboring signaling nodes is fixed. 205 o The transport layer will maintain the following state for each 206 session: 208 1. Previous / next NSIS Entities, for each previous/next hop a 209 branch is created. Multiple branches may exist e.g. in case of 210 route changes. 211 2. Flow identifier, consisting of a source and destination IP 212 address. 213 3. Session identifier, this should be a global unique number used 214 to identify state. 215 4. Client type, which specifies the client that is associated with 216 the transport state. Note that only one client is allowed per 217 session. 219 Security Considerations 221 The transport layer provides hop-by-hop security. It should allow 222 for at least authentication and message integrity between 223 neighboring signaling nodes. Confidentiality (i.e. encryption) may 224 be desirable. In order to provide the required functionality 225 existing (and proven!) security mechanisms such as IPSec or TLS 226 should be used. 228 References 230 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 231 9, RFC 2026, October 1996. 233 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 234 Levels", BCP 14, RFC 2119, March 1997. 236 3 Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and Van 237 den Bosch, S., "Next steps in signaling: Framework", Internet 238 Engineering Task Force, draft-ietf-nsis-fw-02.txt, work in 239 progress, March 2003. 241 4 Schulzrinne, H., Tschofenig, H., Fu, X., McDonald, A., "CASP - 242 Cross-Application Signaling Protocol", draft-schulzrinne-nsis- 243 casp-01.txt, work in progress, March 2003. 245 5 Buchli, M., Waegeman, E., Conte, A., "A Network Service Layer 246 Protocol for QoS signaling", draft-buchli-nsis-nslp-00.txt, May 247 2003. 249 Author's Addresses 251 Maarten Buchli 252 Alcatel 253 Francis Wellesplein 1 254 B-2018 Antwerpen, BELGIUM 255 Phone: +32 3 240 7081 256 Email: maarten.buchli@alcatel.be 258 Eric Waegeman 259 Alcatel 260 Francis Wellesplein 1 261 B-2018 Antwerpen, BELGIUM 262 Email: eric.waegeman@alcatel.be 264 Sven Van den Bosch 265 Alcatel 266 Francis Wellesplein 1 267 B-2018 Antwerpen, BELGIUM 268 Email: sven.van_den_bosch@alcatel.be