idnits 2.17.1 draft-ietf-manet-dlep-lid-extension-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8175]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2019) is 1737 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group R. Taylor 3 Internet-Draft Airbus Defence & Space 4 Intended status: Standards Track S. Ratliff 5 Expires: January 26, 2020 VT iDirect 6 July 25, 2019 8 DLEP Link Identifier Extension 9 draft-ietf-manet-dlep-lid-extension-05 11 Abstract 13 The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a 14 protocol for modems to advertise the status of wireless links between 15 reachable destinations to attached routers. The core specification 16 of the protocol assumes that every modem in the radio network has an 17 attached DLEP router, and requires that the MAC address of the DLEP 18 interface on the attached router be used to identify the destination 19 in the network, for purposes of reporting the state and quality of 20 the link to that destination. 22 This document describes a DLEP Extension allowing modems that do not 23 meet the strict requirement above to use DLEP to describe link 24 availability and quality to one or more destinations reachable beyond 25 a device on the Layer 2 domain. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 26, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Identifier Restrictions . . . . . . . . . . . . . . . . . 5 67 2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. New Data Items . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Link Identifier Length Data Item . . . . . . . . . . . . 6 70 3.2. Link Identifier Data Item . . . . . . . . . . . . . . . . 6 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The Dynamic Link Exchange Protocol (DLEP) [RFC8175] describes a 79 protocol for modems to advertise the status of wireless links between 80 reachable destinations to attached routers. The core specification 81 of the protocol assumes that every modem in the radio network has an 82 attached DLEP router, and requires that the MAC address of the DLEP 83 interface on the attached router be used to identify the destination 84 in the network, for purposes of reporting the state and quality of 85 the link to that destination. 87 This document describes a DLEP Extension allowing modems that do not 88 meet the strict requirement above to use DLEP to describe link 89 availability and quality to one or more destinations reachable beyond 90 a device on the Layer 2 domain. 92 As with core DLEP, a router can use this knowledge to influence any 93 routing or flow-control decisions regarding traffic to this 94 destination, understanding that such traffic flows via Layer 3. 96 1.1. Terminology 98 Local Layer 2 domain: The Layer 2 domain that links the router and 99 modem participants of the current DLEP session. 101 Layer 3 DLEP Destination: A DLEP Destination that is not directly 102 addressable within the local Layer 2 domain, but is reachable via 103 a node addressable within the local Layer 2 domain. 105 Gateway Node: The last device with a MAC address reachable in the 106 local Layer 2 domain on the path from the DLEP router participant, 107 towards the Layer 3 DLEP Destination. This device is commonly the 108 DLEP peer modem but could be another DLEP Destination in the Layer 109 2 domain. 111 1.2. Applicability 113 This extension was designed primarily to address the following use 114 cases: 116 1. A radio system that does not operate in Layer 2 bridge mode, but 117 instead provides Layer 3 connectivity between destinations, often 118 using its own embedded Layer 3 routing function. 120 2. A point-to-multipoint tunnel system, such as an SD-WAN 121 deployment, where the tunnel provider acts as a modem, having 122 knowledge of the characteristics of the underlay network, and 123 providing that information as availability and metrics between 124 tunnel endpoints in the overlay network. 126 3. A modem that provides connectivity to a remote wide-area network 127 via a wireless link, but the concept of a Layer 2 reachable 128 remote router does not apply. An example of such a modem would 129 be an LTE device or 802.11 station that provides variable 130 connectivity to the Internet. 132 This list of use-cases is not exhaustive, and this extension may well 133 be applicable to future, currently unforeseen, use-cases. 135 1.3. Requirements 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Operation 145 To refer to a Layer 3 DLEP Destination, the DLEP session participant 146 adds a Link Identifier Data Item (Section 3.2) to the relevant 147 Destination Message, and (as usual) includes a MAC Address Data Item. 148 When paired with a Link Identifier Data Item, the MAC Address Data 149 Item MUST contain the MAC address of the Gateway Node. 151 As only modems are initially aware of Layer 3 DLEP Destinations, Link 152 Identifier Data Items referring to a new link MUST first appear in a 153 DLEP Destination Up Message from the modem to the router. Once a 154 link has been identified in this way, Link Identifier Data Items may 155 be used by either DLEP participant during the lifetime of a DLEP 156 session. Because of this, a router MUST NOT send a DLEP Destination 157 Announce Message containing a Link Identifier Data Item referring to 158 a link that has not been mentioned in a prior DLEP Destination Up 159 Message. If a modem receives such a message, it MUST terminate the 160 session by issuing a Session Termination Message containing a Status 161 Data Item with status code set to 131 'Invalid Destination' and 162 transition to the Session Termination state. 164 Because the MAC Address associated with any DLEP Destination Message 165 containing a Link Identifier Data Item is not the Layer 2 address of 166 the final destination, all DLEP Destination Up Messages containing a 167 Link Identifier Data Item MUST contain Layer 3 information. In the 168 case of modems that provide Layer 3 wide area network connectivity 169 between devices, this means one or more IPv4 or IPv6 Address Data 170 Items providing the Layer 3 address of the final destination. When 171 referring to some upstream backbone network infrastructure, this 172 means one or more IPv4 or IPv6 Attached Subnet Data Items, for 173 example: '0.0.0.0/0' or '::/0'. This allows the DLEP peer router to 174 understand the properties of the link to those routes. 176 When the DLEP peer router wishes to route packets to the Layer 3 DLEP 177 Destination, the MAC address associated with the Gateway Node MUST be 178 used as the Layer 2 destination of the packet, if it wishes to use 179 the modem network to forward the packet. 181 As routers populate their routing information base with the IP 182 address of the next hop router towards a destination, implementations 183 supporting this extension SHOULD announce at least one valid IPv4 or 184 IPv6 addresses of the Gateway Node, this removes the need for the 185 router to use an additional IP address resolution protocol before 186 adding the route to its routing information base. 188 2.1. Identifier Restrictions 190 A Link Identifier is by default 4 octets in length. If a modem 191 wishes to use a Link Identifier of a different length, it MUST be 192 announced using the Link Identifier Length Data Item (Section 3.1) 193 contained in the DLEP Session Initialization Response message sent by 194 the modem to the router. 196 During the lifetime of a DLEP session, the length of Link Identifiers 197 MUST remain constant, i.e. the Length field of the Link Identifier 198 Data Item MUST NOT differ between destinations. 200 The method for generating Link Identifiers is a modem implementation 201 matter and out of scope of this document. Routers must not make any 202 assumptions about the meaning of Link Identifiers, or how Link 203 Identifiers are generated. 205 Within a single DLEP session, all Link Identifiers MUST be unique per 206 MAC Address. This means that a Layer 3 DLEP Destination is uniquely 207 identified by the pair: {MAC Address,Link Identifier}. 209 Link Identifiers MUST NOT be reused, i.e. a {MAC Address,Link 210 Identifier} pair that has been used to refer to one Layer 3 DLEP 211 Destination MUST NOT be recycled to refer to a different destination 212 within the lifetime of a single DLEP session. 214 2.2. Negotiation 216 To use this extension, as with all DLEP extensions, the extension 217 MUST be announced during DLEP session initialization. A router 218 advertises support by including the value 'Link Identifiers', TBD1 219 (Section 5), in the Extension Data Item within the Session 220 Initialization Message. A modem advertises support by including the 221 value 'Link Identifiers' in the Extension Data Item within the 222 Session Initialization Response Message. If both DLEP peers 223 advertise support for this extension then Link Identifier Data Items 224 can be included in DLEP Messages. 226 If a modem requires support for this extension in order to describe 227 destinations, and the router does not advertise support, then the 228 modem MUST NOT include a Link Identifier Data Item in any DLEP 229 Message. However, the modem SHOULD NOT immediately terminate the 230 DLEP session, rather it SHOULD use a combination of DLEP Session 231 Messages and DLEP Attached Subnet Data Items to provide general 232 information. 234 3. New Data Items 236 This extension introduces two new DLEP Data Items: the Link 237 Identifier Data Item (Section 3.2) used to identify a Layer 3 link at 238 or beyond a destination, and the Link Identifier Length Data Item 239 (Section 3.1) used to announce the length of Link Identifiers at 240 session initialization. 242 3.1. Link Identifier Length Data Item 244 The Link Identifier Length Data Item is used by a DLEP modem 245 implementation to specify the length of Link Identifier Data Items. 246 It MUST be used during Session Initialization, contained in a Session 247 Initialization Response Message, if the specified length is not the 248 default value of 4 octets. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Data Item Type | Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Link Identifier Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Data Item Type: TBD2 (Section 5) 260 Length: 2 262 Link Identifier Length: The length, in octets, of Link Identifiers 263 used by the DLEP modem for this session. 265 A Link Identifier Length Data Item that specifies a Link Identifier 266 Length of 4 octets (the default) is valid, even if it has no effect. 268 3.2. Link Identifier Data Item 270 The Link Identifier Data Item MAY be used wherever a MAC Address Data 271 Item is defined as usable in core DLEP. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Data Item Type | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Link Identifier... : 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Data Item Type: TBD3 (Section 5) 282 Length: The length of the Data Item, by default 4, but may be 283 different if a Link Identifier Length Data Item (Section 3.1) has 284 been announced during session initialization. 286 Link Identifier: The unique identifier of the Layer 3 DLEP 287 Destination. This Link Identifier has no implicit meaning and is 288 only used to discriminate between multiple links. 290 4. Security Considerations 292 As an extension to the core DLEP protocol, the security 293 considerations of that protocol apply to this extension. This 294 extension adds no additional security mechanisms or features. 296 None of the features introduced by this extension require extra 297 consideration by an implementation. 299 5. IANA Considerations 301 Upon approval of this document, IANA is requested to: 303 o Assign a new DLEP Extensions Registry value (TBD1) from the 304 Specification Required section, named "Link Identifiers". 306 o Assign a new DLEP Data Item Type Values Registry value (TBD2) from 307 the Specification Required section, named "Link Identifier 308 Length". 310 o Assign a new DLEP Data Item Type Values Registry value (TBD3) from 311 the Specification Required section, named "Link Identifier". 313 6. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 325 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 326 DOI 10.17487/RFC8175, June 2017, 327 . 329 Authors' Addresses 331 Rick Taylor 332 Airbus Defence & Space 333 Quadrant House 334 Celtic Springs 335 Coedkernew 336 Newport NP10 8FZ 337 UK 339 Email: rick.taylor@airbus.com 341 Stan Ratliff 342 VT iDirect 343 13861 Sunrise Valley Drive, Suite 300 344 Herndon, VA 20171 345 USA 347 Email: sratliff@idirect.net