idnits 2.17.1 draft-dlep-lid-00.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 ([I-D.ietf-manet-dlep]), 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 (May 30, 2017) is 2520 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 informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 May 30, 2017 5 Expires: December 1, 2017 7 Link Identifier Extension to DLEP 8 draft-dlep-lid-00 10 Abstract 12 There exists a class of modems that wish to support the Dynamic Link 13 Exchange Protocol (DLEP) [I-D.ietf-manet-dlep] but do not present a 14 single Layer 2 network domain as required by DLEP. Such devices may 15 be: 17 o Modems that maintain a varying link to some upstream backbone 18 network infrastructure, where the ability to announce link state 19 and DLEP metrics is desired, but the concept of a DLEP destination 20 router for the backbone does not apply. Examples of such devices 21 can include LTE modems, IEEE 802.11 stations not in ad-hoc mode, 22 and some satellite terminals. 24 o Modems that provide Layer 3 wide area network connectivity between 25 devices, where individual DLEP destinations do exist, but are not 26 directly reachable by MAC address. 28 This document introduces an optional extension to the core DLEP 29 specification, allowing DLEP to be used between routers and modems 30 that operate in this way. 32 Note: 34 o This document is intended as an extension to the core DLEP 35 specification, and readers are expected to be fully conversant 36 with the operation of core DLEP. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 1, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1. Identifier Restrictions . . . . . . . . . . . . . . . . . 4 76 2.2. Link Identifier Data Item . . . . . . . . . . . . . . . . 4 77 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. DLEP Link Identifier Flag . . . . . . . . . . . . . . . . 5 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 82 5.2. Informative References . . . . . . . . . . . . . . . . . 6 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 85 1. Introduction 87 The Dynamic Link Exchange Protocol (DLEP) [I-D.ietf-manet-dlep] 88 describes a protocol for modems to advertise the status of wireless 89 links between reachable destinations to attached routers. The core 90 specification of the protocol assumes that every modem in the radio 91 network has an attached DLEP router, and the MAC address of the DLEP 92 interface on the router is used to identify the destination in the 93 network for purposes of reporting the state and quality of the link 94 to that destination. 96 This document describes a DLEP Extension allowing modems that do not 97 meet the strict requirement that DLEP must be implemented on a single 98 Layer 2 domain to use DLEP to describe link state and quality to one 99 or more destinations reachable only at Layer 3. 101 To enable routers to take advantage of the DLEP protocol this 102 extension adds a single enhancement to the DLEP protocol: A new Link 103 Identifier Data Item. This Data Item replaces the use of the MAC 104 Address Data Item whenever the DLEP destination does not have a 105 router reachable by MAC address. 107 By using the Link Identifier Data Item, the modem implementation can 108 announce the link state and quality to a uniquely identified 109 destination in the network, either logical or physical, explicitly 110 indicating that the destination is not reachable via a single Layer 2 111 domain. A router can use this knowledge to influence any routing or 112 flow-control decisions regarding traffic to this destination, 113 understanding that such decisions apply at Layer 3. 115 1.1. Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 2. Operation 124 To use this extension, as with all DLEP extensions, the extension 125 MUST be announced during DLEP session initialization. A router 126 advertises support by including the value 'Link Identitifers' (TBD1) 127 in the Extension Data Item within the Session Intitialization 128 Message. A modem advertises support by including the value 'Link 129 Identitifers' (TBD1) in the Extension Data Item within the Session 130 Intitialization Response Message. If both DLEP peers advertise 131 support for this extension then the Link Identifier Data Item MAY be 132 used. 134 If a modem requires support for this extension in order to describe 135 destinations, and the router does not advertise support, then the 136 modem MUST NOT include a Link Identifier Data Item in any DLEP 137 Message. However, the modem SHOULD NOT immediately terminate the 138 DLEP session, rather it should use session-wide DLEP Data Items to 139 announce general information about all reachable destinations via the 140 modem. By doing this, a modem allows a router not supporting this 141 extension to at least make a best guess at the state of any reachable 142 network. A modem MUST NOT attempt to re-use the MAC Address Data 143 Item to perform some kind of sleight-of-hand, assuming that the 144 router will notice the DLEP Peer Type of the modem is special in some 145 way. 147 Even when the Link Identifiers extension is in use for a DLEP 148 session, either peer MAY send and receive Messages concerning DLEP 149 destinations that are reachable via a single Layer 2 domain, using 150 the standard DLEP MAC Address Data Item. This allows modems that 151 support hybrid functionality of directly connected Layer 2 peers, as 152 well as upstream links to some kind of infrastructure, as well as 153 multicast logical destinations. 155 2.1. Identifier Restrictions 157 Within a single DLEP session, all identifiers used by this extension, 158 both logical and physical, MUST be unique, and it is RECOMMENDED that 159 they be 4 octets in length. 161 Identifiers MUST NOT be reused, i.e. an indentifier that has been 162 used to refer to one destination MUST NOT be recycled to refer to a 163 different destination within the lifetime of a single DLEP session. 165 The method for generating identifiers is a modem implementation 166 matter and out of scope of this document. Routers MUST NOT make any 167 assumptions about the meaning of identifiers, or how identifiers are 168 generated. 170 2.2. Link Identifier Data Item 172 The Link Identifier Data Item MAY be used whenever a MAC Address Data 173 Item is defined as useable in core DLEP. A single Link Identifier 174 Data Item MUST only be used in place of a single MAC Address Data 175 Item. A Link Identifier Data Item MUST NOT appear in the same DLEP 176 Message as a MAC Address Data Item. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Data Item Type | Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Flags | Link Identifier... : 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Data Item Type: TBD2 188 Length: >0, 4 RECOMMENDED. 190 Flags: Flags field, defined below. 192 Link Identifier: The unique identifier of the link destination. 193 This identifier has no implicit meaning and is only used to 194 discriminate between multiple links. 196 The Flags field is defined as: 198 0 1 2 3 4 5 6 7 199 +-+-+-+-+-+-+-+-+ 200 | Reserved | 201 +-+-+-+-+-+-+-+-+ 203 Reserved: MUST be zero. Left for future assignment. 205 The Flags field is here because I think it might be useful, but I 206 can't think how currently. 208 3. Security Considerations 210 As an extension to the core DLEP protocol, the security 211 considerations of that protocol apply to this extension. This 212 extension adds no additional security mechanisms or features. 214 None of the features introduced by this extension require extra 215 consideration by an implementation. 217 4. IANA Considerations 219 Upon approval of this document, IANA is requested to: 221 o Assign a new value (TBD1) from the Specification Required section 222 of the DLEP Extensions Registry, named "Link Identifiers". 224 o Assign a new value (TBD2) from the Specification Required section 225 of the DLEP Data Item Type Values Registry, named "Link 226 Identifier". 228 4.1. DLEP Link Identifier Flag 230 Upon approval of this document, IANA is requested to create a new 231 DLEP registry, named "Link Identifier Flags". 233 The following table provides initial registry values and the 234 [RFC5226] defined policies that should apply to the registry: 236 +------------+------------------------------------+ 237 | Bit | Description/Policy | 238 +------------+------------------------------------+ 239 | 0-7 | Unassigned/Specification Required | 240 +------------+------------------------------------+ 242 5. References 244 5.1. Normative References 246 [I-D.ietf-manet-dlep] 247 Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 248 Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- 249 ietf-manet-dlep-29 (work in progress), March 2017. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 5.2. Informative References 258 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 259 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 260 DOI 10.17487/RFC5226, May 2008, 261 . 263 Author's Address 265 Rick Taylor 266 Airbus Defence & Space 267 Quadrant House 268 Celtic Springs 269 Coedkernew 270 Newport NP10 8FZ 271 UK 273 Email: rick.taylor@airbus.com