idnits 2.17.1 draft-turner-diff-nhrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 29 has weird spacing: '...oviding diffe...' == Line 63 has weird spacing: '...created betwe...' == Line 69 has weird spacing: '...maps to an...' == Line 119 has weird spacing: '...ingress and e...' == Line 201 has weird spacing: '...gnaling param...' -- 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 (March 1998) is 9540 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) ** Obsolete normative reference: RFC 1349 (ref. '1') (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Turner S.,Staegemeir B. 2 INTERNET DRAFT SITA / Equant R&D 3 Expires September 1998 March 1998 5 Differentiated Services over Symmetric NHRP Shortcuts 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress". 21 Please check the 1id-abstracts.txt listing contained in the internet- 22 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 23 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 24 current status of any Internet Draft. 26 Abstract 28 There is a need, for relatively simple and scaleable methods of 29 providing differentiated classes of service for IP traffic over 30 various WAN media, to support different types of applications and 31 specific business requirements. The Differentiated Services approach 32 to providing quality of service (QoS) in Networks, employs a small, 33 well-defined set of building blocks from which a variety of services 34 may be built. A small bit-pattern in each packet in the IPv4 "TOS 35 octet" or in the IPv6 "Traffic Class octet" is used to mark a packet 36 to receive a differentiated forwarding treatment or per-hop behavior 37 at each network node. IETF Working Groups will standardize a common 38 layout for both octets, called the "DS byte" superseding the IPv4 TOS 39 octet definitions or RFC 1349 [1]. 41 The goal of this contribution is to suggest how the Next Hop 42 Resolution Protocol (NHRP) may be extended and deployed in 43 conjunction with the IP ToS octet (DS-Byte) to create both 44 differentiated forwarding and differentiated class of service over 45 an NBMA network such as ATM or Frame-Relay. 47 In the proposed solution, any SVC created between the same two points 48 in an NBMA network will be used bi-directionally by traffic with the 49 same class of service. This is achieved by extending the scope of 50 the existing NHRP protocol to include QoS information in the 51 extensions part of both the NHRP resolution request and resolution 52 reply, and by implementing a NBMA addressing scheme that dynamically 53 maps CoS, to subaddresses that are unique within the NBMA network. 55 The proposal is compliant with the NHRP specifications, and every 56 effort is made by the proposal to build on the work currently 57 underway within the IETF that is attempting to standardize on the 58 use of the ToS octet (DS-byte) within the IP datagram. 60 1. NHRP Default Operation 62 Within the scope of existing definitions [2], NHRP shortcuts may be 63 created between hosts, or ingress and egress routers at the edges of 64 an NBMA network, with NHRP cache entries mapping remote layer 3 65 prefixes (IP hosts, subnets or BGP next-hops) onto SVCs. These 66 cache entries may only be added after specific datagrams matching 67 defined trigger criteria send an NHRP resolution request, and when 68 that NHRP request is successfully returned. If in the NHRP 69 resolution reply, the remote NBMA subaddress of the NHS maps to an 70 existing SVC that directly interconnects NHC and NHS, then the best 71 match prefix in the forwarding table, that allowed the initial 72 forwarding of the datagram over the default path, is typically 73 added to the NHRP cache, and is mapped onto the existing SVC. This 74 means that all traffic flows between the same pair of ingress and 75 egress points whose L3 destination address is mapped by the NHRP 76 cache, will be merged onto the same NHRP shortcut. 78 This default behaviour is very useful, particularly for network 79 bootstrapping and for traffic engineering purposes, in order to 80 minimize the number of routed hops and to reduce congestion in the 81 core of the IP network. 83 2. Extension of NHRP for Differentiated Forwarding 85 The current applicability of NHRP severely limits the possibilities 86 to use NHRP as a mechanism, or as part of a mechanism, to create 87 Differentiated Classes-of-Service (CoS) across an NBMA network. This 88 is because the NHRP cache entries that indicate whether a shortcut 89 should be used or not, are based on layer 3 prefixes, and although a 90 delay sensitive application may in fact trigger the shortcut SVC, 91 once created, this shortcut will be used by all traffic whose L3 92 destination is included in the cache. This in turn means that all 93 traffic with a mixture of classes of service will be competing for 94 resources over the same forwarding path, unless a mechanism is found 95 which allows multiple shortcuts, and where path selection is based on 96 the class of service information in the traffic flows. 98 However, using multiple SVCs between the same ingress and egress pair 99 is problematic for two main reasons : 101 i) You need to introduce an additional element to the trigger 102 criteria that specifies whether to use an existing SVC or not. 104 ii) If another SVC is created for a specific policy at one end, in 105 order to use this SVC in full duplex mode, both the policy and 106 the mapping to an SVC must be known and synchronized at each end. 108 Problem (i) is not insurmountable, but the corresponding changes to 109 the NHRP cache structure may make it difficult to implement rapid 110 packet forwarding over the correct SVC. 112 Problem (ii) is more difficult, and requires the introduction of 113 either a "central policy control point" ("one more server") and 114 out-of-band synchronisation, or using a new "protocol" that allows 115 end-to-end in-band correlation of layer 3 information with SVCs. This 116 is definitely a non-trivial problem! 118 A compromise is suggested to permit multiple SVCs between the same 119 ingress and egress points, and to allow both differentiated 120 forwarding and differentiated class of service. 122 The primary purpose of this strategy is to allow the creation of 123 shortcuts, and through the use of differentiated forwarding signaled 124 by the ToS byte in IP datagrams, to prevent "low class" traffic 125 mixing with "high class" traffic. Thus we create more performance 126 determinacy. 128 3. Per Class-of-Service Shortcuts 130 The proposal has three components: 132 i) A simple way to map an IP packet with a specific Class of 133 Service information in the DS-byte to a corresponding SVC with 134 an appropriate layer 2 traffic class. The number of possible 135 SVCs between the same source and destination prefix is 136 therefore limited to the number of relevant DS-byte encodings, 137 e.g. as defined in RFC 1349. This does not imply that each 138 defined CoS always maps onto a unique SVC, since different CoS 139 may be grouped and mapped onto a shared SVC. 141 ii) The local association or mapping by Next Hop Resolution Clients 142 (NHC) and Next Hop Resolution Servers (NHS), between a single 143 class of service or a group of classes of service, and a unique 144 NBMA subaddress. 146 iii) A protocol extension to ensure that all SVC based shortcuts are 147 used in both directions. This avoids the protocol and 148 processing overhead for SVC creation in the reverse direction, 149 and eliminates any additional set up delay and potential 150 performance problems caused by asymmetric paths. 152 The proposed "CoS enabled NHRP" works in the following way : 154 i) An NHRP request policy is directly associated with the IP ToS 155 byte or specific elements in it. An obvious example would be 156 triggers based on the four precedence bits and its eight defined 157 classes of services in RFC 1349. 159 ii) This policy should be consistently defined through NHRP 160 "triggers" on all NHCs in the NBMA network. 162 iii) Each NHC and NHS makes a local association between a Class of 163 Service, identified by the ToS byte, and a globally unique NBMA 164 subaddress. This NBMA subaddress may be formed by appending or 165 including a locally managed addressing element termed the "CoS 166 designator", to the globally known and unique NBMA subaddress. 167 e.g. In the case of a given router or host connected to an ATM 168 network, each CoS is mapped to a specific value of selector byte 169 that is then appended to the same 13 byte prefix and 6 byte 170 ESI, to form a set of unique NSAPs. Each NSAP thus globally 171 identifies the NHS or NHC, and provides local significance as 172 to the CoS assigned to each SVC shortcut. This association 173 should be dynamically mapped according to the local 174 implementation and means that the number of NBMA addresses or 175 subaddresses per NHRP station must be greater than or equal to 176 the number of CoS available across the NBMA subnetwork. 178 iv) When an NHRP client forwards a datagram into the NBMA cloud with 179 a ToS byte that matches the trigger policy, an NHRP resolution 180 request is created and sent. (It is assumed that no SVC 181 shortcuts exist). This NHRP request contains the ToS byte in 182 the IP packet that triggered it, and is copied into the 183 Extensions part of the NHRP resolution request. 185 v) When the NHRP request is received by the NHS at the egress point 186 of the NBMA network, the ToS extension is examined, and the NBMA 187 address returned in the reply is specific to that ToS. i.e. the 188 CoS designator that is locally associated with the value in the 189 ToS extension is included in the NBMA address returned in the 190 NHRP resolution reply. 192 vi) When the NHRP reply is received by the NHC that triggered the 193 initial request, an NHRP cache entry is created that maps the L3 194 reachability information associated with the destination to the 195 NBMA address contained in the resolution reply. This NHRP cache 196 entry is now extended to include the ToS information sent in the 197 resolution request and suqsequently returned in the resolution 198 reply. An SVC to the remote NHS for this CoS can be created 199 immediately or on receipt of a subsequent packet that matches 200 the cached information. The time at which the SVC is created 201 and any L2 QoS related signaling parameters are implementation 202 specific.) 204 vii) Subsequent packets sent by the NHC are now compared to the NHRP 205 cache entry in terms of destination IP address and the ToS byte. 207 Now we distinguish three cases : 209 i) If a match is found on both conditions, then the packet is 210 forwarded over the associated SVC. 212 ii) If a match is not found, and the QoS information in the 213 packet header matches the trigger policy, then a new NHRP 214 request is sent out as described previously. When the reply 215 is received and both destination NBMA address and ToS 216 information is the same as an existing NBMA address/ToS pair, 217 then the destination IP prefix is added to the NHRP cache, 218 and the entry is mapped to the existing SVC. 220 iii) In the case of (ii), if the reply contains an NBMA address 221 /ToS pair that does not map to an existing NHRP cache entry, 222 then a new SVC is requested to the NBMA subaddress contained 223 in the reply, and a new cache entry created as before. 225 viii) In the reverse path, i.e. when the roles of NHC and NHS are 226 reversed, an identical process is followed. In this case, 227 since an NHS should consistently return an NBMA subaddress 228 that maps to a given CoS or group of CoS, then it is 229 straightforward to determine if an SVC with the given CoS 230 already exists, even if the SVC was remotely initiated. 232 4. Full Duplex Mode of Operation and Asymetric shortcut avoidance 234 To avoid two SVCs with the same CoS being used unidirectionally 235 between the same pair of NHRP stations, the following simple 236 algorithm is proposed. 238 When an NHRP resolution request is received by the NHS, a lookup is 239 performed that keys on the source NBMA subaddress without CoS 240 designator i.e. without the selector in the ATM case. 242 If no match is found, then continue as described previously. 244 If a match is found, extract the requested CoS in the extensions part 245 of the NHRP Resolution request and: 247 i) If neither the CoS nor the CoS designator from the NHRP 248 resolution request are found in the CoS mapping table, then 249 continue. 251 ii) If both the CoS and the CoS designator are found in the table, 252 and they are mapped together, then continue. 254 iii) If the CoS is found but it maps to a different CoS designator, 255 then send a Resolution Reply with a NAK code of 4 256 "Administratively Prohibited" 258 iv) If the CoS designator is found but it maps to a different CoS, 259 then send a Resolution Reply with a NAK code of 4, 260 "Administratively Prohibited" 262 When a resolution reply is received by the NHC, then do the following: 264 i) If NAK is received, then abort all attempts to include L3 265 destination in NHRP cache. 267 ii) If the reply is valid, but the Compulsory bit is clear, assume 268 CoS 0, i.e. shortcut forwarding over single SVC only to NHS. 269 (see below) 271 iii) If the reply is valid, and the Compulsory bit is set, then: 273 a) Perform a lookup based on the source NBMA subaddress without 274 CoS designator i.e. without the selector in the ATM case. 276 b) If neither the CoS nor the CoS designator from the NHRP 277 resolution request are found in the CoS mapping table, then 278 continue. 280 c) If both the CoS and the CoS designator are found in the table, 281 and they are mapped together, then continue. 283 d) If the CoS is found but it maps to a different CoS designator, 284 then abort all attempts to include L3 destination in NHRP cache. 286 e) If the CoS designator is found but it maps to a different CoS, 287 then abort all attempts to include L3 destination in NHRP cache. 289 5. Backwards compatibility with existing NHRP Implementations 291 The "Compulsory" bit should be left clear in the NHRP resolution 292 request to allow backwards compatibility with existing NHSs. If the 293 egress router understands the extension and acts upon it, i.e. is 294 performing CoS mapping, then this C bit should be set to 1 in the 295 reply. This will allow the requestor to know whether to perform the 296 asymmetric checking or not, and whether to create multiple SVCs to 297 the same NHS. 299 6. Issues and Scalability 301 The techniques described above would allow the creation of a strongly 302 differentiated class of service within an IP network that primarily 303 uses an NBMA network for interconnection between hosts and or 304 routers. The shortcuts created by NHRP will be exclusive per 305 associated Class-of-Service (rather than per flow), and will be used 306 in full-duplex mode. The forwarding overhead to use a shortcut is 307 "simply" using a combination of both destination address and QoS to 308 hash the NHRP cache. The primary limitation could be the availability 309 of some form of "sub-addressing" scheme for the NHRP clients and 310 servers that allows the local association between the called and 311 calling addresses and a CoS. 313 This solution scales well due to a simple but consistent forwarding 314 Policy definition, the limited number of SVCs, and since the number 315 of NHRP cache entries is limited per CoS per destination prefix. 317 7. Security Considerations 319 Security is not addressed in the current version of this document 321 References 323 [1] Almquist, P. "Type of Service in the Internet Protocol Suite". 324 RFC 1349, July 1992. 326 [2] NMBA Next Hop Resolution Protocol (NHRP) , J. Luciani, 327 D. Katz, D. Piscitello and B. Cole. Work in progress. 329 Authors' Address 331 Steve Turner 332 SITA Network Projects Department. 333 1041, Route des Dolines 334 F-06560 Valbonne / France 335 Phone +33 4 92 96 63 17 336 email st@pt.nce.sita.int 338 Bernd Staegemeir 339 SITA Research & Development 340 1041, Route des Dolines 341 F-06560 Valbonne / France 342 Phone +33 4 92 96 65 40 343 email bst@ed.nce.sita.int