summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8703.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8703.txt')
-rw-r--r--doc/rfc/rfc8703.txt384
1 files changed, 384 insertions, 0 deletions
diff --git a/doc/rfc/rfc8703.txt b/doc/rfc/rfc8703.txt
new file mode 100644
index 0000000..8e9ccc3
--- /dev/null
+++ b/doc/rfc/rfc8703.txt
@@ -0,0 +1,384 @@
+
+
+
+
+Internet Engineering Task Force (IETF) R. Taylor
+Request for Comments: 8703 Airbus Defence & Space
+Category: Standards Track S. Ratliff
+ISSN: 2070-1721 February 2020
+
+
+ Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension
+
+Abstract
+
+ The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to
+ advertise the status of wireless links between reachable destinations
+ to attached routers. The core specification of the protocol (RFC
+ 8175) assumes that every modem in the radio network has an attached
+ DLEP router and requires that the Media Access Control (MAC) address
+ of the DLEP interface on the attached router be used to identify the
+ destination in the network, for purposes of reporting the state and
+ quality of the link to that destination.
+
+ This document describes a DLEP extension that allows modems that do
+ not meet the strict requirement above to use DLEP to describe link
+ availability and quality to one or more destinations reachable beyond
+ a device on the Layer 2 domain.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8703.
+
+Copyright Notice
+
+ Copyright (c) 2020 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Terminology
+ 1.2. Applicability
+ 1.3. Requirements Language
+ 2. Operation
+ 2.1. Identifier Restrictions
+ 2.2. Negotiation
+ 3. New Data Items
+ 3.1. Link Identifier Length Data Item
+ 3.2. Link Identifier Data Item
+ 4. Security Considerations
+ 5. IANA Considerations
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ Authors' Addresses
+
+1. Introduction
+
+ The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to
+ advertise the status of wireless links between reachable destinations
+ to attached routers. The core specification of the protocol
+ [RFC8175] assumes that every modem in the radio network has an
+ attached DLEP router and requires that the MAC address of the DLEP
+ interface on the attached router be used to identify the destination
+ in the network, for purposes of reporting the state and quality of
+ the link to that destination.
+
+ This document describes a DLEP extension that allows modems that do
+ not meet the strict requirement above to use DLEP to describe link
+ availability and quality to one or more destinations reachable beyond
+ a device on the Layer 2 domain.
+
+ As with core DLEP [RFC8175], a router can use this knowledge to
+ influence any routing or flow-control decisions regarding traffic to
+ this destination, understanding that such traffic flows via Layer 3.
+
+1.1. Terminology
+
+ Local Layer 2 domain: The Layer 2 domain that links the router and
+ modem participants of the current DLEP session.
+
+ Layer 3 DLEP Destination: A DLEP Destination that is not directly
+ addressable within the local Layer 2 domain but is reachable via a
+ node addressable within the local Layer 2 domain.
+
+ Gateway Node: The last device with a MAC address reachable in the
+ local Layer 2 domain on the path from the DLEP router participant
+ towards the Layer 3 DLEP Destination. This device is commonly the
+ DLEP peer modem but could be another DLEP Destination in the Layer
+ 2 domain.
+
+1.2. Applicability
+
+ This extension was designed primarily to address the following use
+ cases:
+
+ 1. A radio system that does not operate in Layer 2 bridge mode but
+ instead provides Layer 3 connectivity between destinations, often
+ using its own embedded Layer 3 routing function.
+
+ 2. A point-to-multipoint tunnel system, such as a software-defined
+ wide-area network (SD-WAN) deployment, where the tunnel provider
+ acts as a modem that has knowledge of the characteristics of the
+ underlay network and provides that information as availability
+ and metrics between tunnel endpoints in the overlay network.
+
+ 3. A modem that provides connectivity to a remote wide-area network
+ via a wireless link, but the concept of a Layer 2 reachable
+ remote router does not apply. An example of such a modem would
+ be an LTE device or 802.11 station that provides variable
+ connectivity to the Internet.
+
+ This list of use cases is not exhaustive, and this extension may well
+ be applicable to future, currently unforeseen, use cases.
+
+1.3. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. Operation
+
+ To refer to a Layer 3 DLEP Destination, the DLEP session participant
+ adds a Link Identifier Data Item (Section 3.2) to the relevant
+ Destination Message and (as usual) includes a MAC Address Data Item.
+ When paired with a Link Identifier Data Item, the MAC Address Data
+ Item MUST contain the MAC address of the Gateway Node.
+
+ As only modems are initially aware of Layer 3 DLEP Destinations, Link
+ Identifier Data Items referring to a new link MUST first appear in a
+ DLEP Destination Up Message from the modem to the router. Once a
+ link has been identified in this way, Link Identifier Data Items may
+ be used by either DLEP participant during the lifetime of a DLEP
+ session. Because of this, a router MUST NOT send a DLEP Destination
+ Announce Message containing a Link Identifier Data Item referring to
+ a link that has not been mentioned in a prior DLEP Destination Up
+ Message. If a modem receives such a message, it MUST terminate the
+ session by issuing a Session Termination Message containing a Status
+ Data Item with status code set to 131 ('Invalid Destination') and
+ transition to the Session Termination state. If a router receives a
+ Destination Up Message specifying a Link Identifier that has already
+ been used, the router MUST respond with a Destination Up Response
+ Message containing a Status Data Item with status code set to 130
+ ('Invalid Data') and transition to the Session Termination state.
+
+ Because the MAC address associated with any DLEP Destination Message
+ containing a Link Identifier Data Item is not the Layer 2 address of
+ the final destination, all DLEP Destination Up Messages containing a
+ Link Identifier Data Item MUST contain Layer 3 information. In the
+ case of modems that provide Layer 3 wide area network connectivity
+ between devices, this means one or more IPv4 or IPv6 Address Data
+ Items providing the Layer 3 address of the final destination. When
+ referring to some upstream backbone network infrastructures, this
+ means one or more IPv4 or IPv6 Attached Subnet Data Items, for
+ example: '0.0.0.0/0' or '::/0'. This mechanism allows the DLEP peer
+ router to understand the properties of the link to those routes. The
+ address or addresses in the IPv4 or IPv6 Address Data Items MUST be
+ the addresses in use on the public side of any Network Address
+ Translation.
+
+ When the DLEP peer router wishes to route packets to the Layer 3 DLEP
+ Destination, the MAC address associated with the Gateway Node MUST be
+ used as the Layer 2 destination of the packet if it wishes to use the
+ modem network to forward the packet.
+
+ As routers populate their Routing Information Base with the IP
+ address of the next-hop router towards a destination, implementations
+ supporting this extension SHOULD announce at least one valid IPv4 or
+ IPv6 addresses of the Gateway Node; this removes the need for the
+ router to use an additional IP address resolution protocol before
+ adding the route to its Routing Information Base.
+
+2.1. Identifier Restrictions
+
+ A Link Identifier is, by default, 4 octets in length. If a modem
+ wishes to use a Link Identifier of a different length, it MUST be
+ announced using the Link Identifier Length Data Item (Section 3.1)
+ contained in the DLEP Session Initialization Response Message sent by
+ the modem to the router.
+
+ During the lifetime of a DLEP session, the length of Link Identifiers
+ MUST remain constant, i.e., the Length field of the Link Identifier
+ Data Item MUST NOT differ between destinations.
+
+ The method for generating Link Identifiers is a modem implementation
+ matter and out of scope of this document. Routers must not make any
+ assumptions about the meaning of Link Identifiers or how Link
+ Identifiers are generated.
+
+ Within a single DLEP session, all Link Identifiers MUST be unique per
+ MAC address. This means that a Layer 3 DLEP Destination is uniquely
+ identified by the pair: {MAC Address,Link Identifier}.
+
+ Link Identifiers MUST NOT be reused, i.e., a {MAC Address,Link
+ Identifier} pair that has been used to refer to one Layer 3 DLEP
+ Destination MUST NOT be used again within the lifetime of a single
+ DLEP peer-to-peer session.
+
+2.2. Negotiation
+
+ To use this extension, as with all DLEP extensions, the extension
+ MUST be announced during DLEP session initialization. A router
+ advertises support by including the value 3 ('Link Identifiers')
+ (Section 5), in the Extension Data Item within the Session
+ Initialization Message. A modem advertises support by including the
+ value 3 ('Link Identifiers') in the Extension Data Item within the
+ Session Initialization Response Message. If both DLEP peers
+ advertise support for this extension, then Link Identifier Data Items
+ can be included in DLEP Messages.
+
+ If a modem requires support for this extension in order to describe
+ destinations and the router does not advertise support, then the
+ modem MUST NOT include a Link Identifier Data Item in any DLEP
+ Message. However, the modem SHOULD NOT immediately terminate the
+ DLEP session; rather, it SHOULD use a combination of DLEP Session
+ Messages and DLEP Attached Subnet Data Items to provide general
+ information.
+
+3. New Data Items
+
+ This extension introduces two new DLEP Data Items: 1) the Link
+ Identifier Length Data Item (Section 3.1) used to announce the length
+ of Link Identifiers at session initialization and 2) the Link
+ Identifier Data Item (Section 3.2) used to identify a Layer 3 link at
+ or beyond a destination.
+
+3.1. Link Identifier Length Data Item
+
+ The Link Identifier Length Data Item is used by a DLEP modem
+ implementation to specify the length of Link Identifier Data Items.
+ If the router advertised support by including the value 3 ('Link
+ Identifiers') in the Extension Data Item inside the Session
+ Initialization Message, this Data Item MAY be used in the Session
+ Initialization Response Message if the specified length is not the
+ default value of 4 octets. If the router did not specify support by
+ including the value 3 ('Link Identifiers') in the Extension Data
+ Item, this Data Item MUST NOT be sent.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data Item Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link Identifier Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Data Item Type: 26 (see Section 5)
+
+ Length: 2
+
+ Link Identifier Length: The length, in octets, of Link Identifiers
+ used by the DLEP modem for this session.
+
+ A Link Identifier Length Data Item that specifies a Link Identifier
+ Length of 4 octets (the default) is valid, even if it has no effect.
+
+3.2. Link Identifier Data Item
+
+ The Link Identifier Data Item MAY be used wherever a MAC Address Data
+ Item is defined as usable in core DLEP [RFC8175].
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data Item Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link Identifier... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Data Item Type: 27 (see Section 5)
+
+ Length: The length of the Data Item, by default 4, but may be
+ different if a Link Identifier Length Data Item (Section 3.1) has
+ been announced during session initialization.
+
+ Link Identifier: The unique identifier of the Layer 3 DLEP
+ Destination. This Link Identifier has no implicit meaning and is
+ only used to discriminate between multiple links.
+
+4. Security Considerations
+
+ As an extension to core DLEP [RFC8175], the security considerations
+ of that protocol apply to this extension. This extension adds no
+ additional security mechanisms or features.
+
+ None of the features introduced by this extension require extra
+ security considerations by an implementation.
+
+5. IANA Considerations
+
+ IANA has assigned the following value to the "Extension Type Values"
+ registry within the "Dynamic Link Exchange Protocol (DLEP)
+ Parameters" registry. This new value is in the range with the
+ "Specification Required" [RFC8126] policy.
+
+ +------+------------------+
+ | Code | Description |
+ +======+==================+
+ | 3 | Link Identifiers |
+ +------+------------------+
+
+ Table 1: Addition to
+ the Extension Type
+ Values Registry
+
+ IANA has assigned two new values to the "Data Item Type Values"
+ registry within the "Dynamic Link Exchange Protocol (DLEP)
+ Parameters" registry. These new values are in the range with the
+ "Specification Required" [RFC8126] policy.
+
+ +-----------+------------------------+
+ | Type Code | Description |
+ +===========+========================+
+ | 26 | Link Identifier Length |
+ +-----------+------------------------+
+ | 27 | Link Identifier |
+ +-----------+------------------------+
+
+ Table 2: Additions to the Data
+ Item Type Values Registry
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
+ Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
+ DOI 10.17487/RFC8175, June 2017,
+ <https://www.rfc-editor.org/info/rfc8175>.
+
+6.2. Informative References
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+Authors' Addresses
+
+ Rick Taylor
+ Airbus Defence & Space
+ Quadrant House
+ Celtic Springs
+ Coedkernew
+ Newport
+ NP10 8FZ
+ United Kingdom
+
+ Email: rick.taylor@airbus.com
+
+
+ Stan Ratliff