draft-ietf-manet-dlep-lid-extension-06.txt | rfc8703.txt | |||
---|---|---|---|---|
Mobile Ad hoc Networks Working Group R. Taylor | Internet Engineering Task Force (IETF) R. Taylor | |||
Internet-Draft Airbus Defence & Space | Request for Comments: 8703 Airbus Defence & Space | |||
Intended status: Standards Track S. Ratliff | Category: Standards Track S. Ratliff | |||
Expires: March 13, 2020 VT iDirect | ISSN: 2070-1721 February 2020 | |||
September 10, 2019 | ||||
DLEP Link Identifier Extension | Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension | |||
draft-ietf-manet-dlep-lid-extension-06 | ||||
Abstract | Abstract | |||
The Dynamic Link Exchange Protocol, RFC 8175, describes a protocol | The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to | |||
for modems to advertise the status of wireless links between | advertise the status of wireless links between reachable destinations | |||
reachable destinations to attached routers. The core specification | to attached routers. The core specification of the protocol (RFC | |||
of the protocol assumes that every modem in the radio network has an | 8175) assumes that every modem in the radio network has an attached | |||
attached DLEP router, and requires that the MAC address of the DLEP | DLEP router and requires that the Media Access Control (MAC) address | |||
interface on the attached router be used to identify the destination | of the DLEP interface on the attached router be used to identify the | |||
in the network, for purposes of reporting the state and quality of | destination in the network, for purposes of reporting the state and | |||
the link to that destination. | quality of the link to that destination. | |||
This document describes a DLEP Extension allowing modems that do not | This document describes a DLEP extension that allows modems that do | |||
meet the strict requirement above to use DLEP to describe link | not meet the strict requirement above to use DLEP to describe link | |||
availability and quality to one or more destinations reachable beyond | availability and quality to one or more destinations reachable beyond | |||
a device on the Layer 2 domain. | a device on the Layer 2 domain. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on March 13, 2020. | 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 Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology | |||
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 | 1.2. Applicability | |||
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 | 1.3. Requirements Language | |||
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Operation | |||
2.1. Identifier Restrictions . . . . . . . . . . . . . . . . . 5 | 2.1. Identifier Restrictions | |||
2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. Negotiation | |||
3. New Data Items . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. New Data Items | |||
3.1. Link Identifier Length Data Item . . . . . . . . . . . . 6 | 3.1. Link Identifier Length Data Item | |||
3.2. Link Identifier Data Item . . . . . . . . . . . . . . . . 7 | 3.2. Link Identifier Data Item | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 4. Security Considerations | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5. IANA Considerations | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . 8 | 6. References | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | 6.1. Normative References | |||
6.2. Informative References | ||||
Authors' Addresses | ||||
1. Introduction | 1. Introduction | |||
The Dynamic Link Exchange Protocol (DLEP), RFC 8175, describes a | The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to | |||
protocol for modems to advertise the status of wireless links between | advertise the status of wireless links between reachable destinations | |||
reachable destinations to attached routers. The core specification | to attached routers. The core specification of the protocol | |||
of the protocol assumes that every modem in the radio network has an | [RFC8175] assumes that every modem in the radio network has an | |||
attached DLEP router, and requires that the MAC address of the DLEP | attached DLEP router and requires that the MAC address of the DLEP | |||
interface on the attached router be used to identify the destination | interface on the attached router be used to identify the destination | |||
in the network, for purposes of reporting the state and quality of | in the network, for purposes of reporting the state and quality of | |||
the link to that destination. | the link to that destination. | |||
This document describes a DLEP Extension allowing modems that do not | This document describes a DLEP extension that allows modems that do | |||
meet the strict requirement above to use DLEP to describe link | not meet the strict requirement above to use DLEP to describe link | |||
availability and quality to one or more destinations reachable beyond | availability and quality to one or more destinations reachable beyond | |||
a device on the Layer 2 domain. | a device on the Layer 2 domain. | |||
As with core DLEP, a router can use this knowledge to influence any | As with core DLEP [RFC8175], a router can use this knowledge to | |||
routing or flow-control decisions regarding traffic to this | influence any routing or flow-control decisions regarding traffic to | |||
destination, understanding that such traffic flows via Layer 3. | this destination, understanding that such traffic flows via Layer 3. | |||
1.1. Terminology | 1.1. Terminology | |||
Local Layer 2 domain: The Layer 2 domain that links the router and | Local Layer 2 domain: The Layer 2 domain that links the router and | |||
modem participants of the current DLEP session. | modem participants of the current DLEP session. | |||
Layer 3 DLEP Destination: A DLEP Destination that is not directly | Layer 3 DLEP Destination: A DLEP Destination that is not directly | |||
addressable within the local Layer 2 domain, but is reachable via | addressable within the local Layer 2 domain but is reachable via a | |||
a node addressable within the local Layer 2 domain. | node addressable within the local Layer 2 domain. | |||
Gateway Node: The last device with a MAC address reachable in the | Gateway Node: The last device with a MAC address reachable in the | |||
local Layer 2 domain on the path from the DLEP router participant, | local Layer 2 domain on the path from the DLEP router participant | |||
towards the Layer 3 DLEP Destination. This device is commonly the | towards the Layer 3 DLEP Destination. This device is commonly the | |||
DLEP peer modem but could be another DLEP Destination in the Layer | DLEP peer modem but could be another DLEP Destination in the Layer | |||
2 domain. | 2 domain. | |||
1.2. Applicability | 1.2. Applicability | |||
This extension was designed primarily to address the following use | This extension was designed primarily to address the following use | |||
cases: | cases: | |||
1. A radio system that does not operate in Layer 2 bridge mode, but | 1. A radio system that does not operate in Layer 2 bridge mode but | |||
instead provides Layer 3 connectivity between destinations, often | instead provides Layer 3 connectivity between destinations, often | |||
using its own embedded Layer 3 routing function. | using its own embedded Layer 3 routing function. | |||
2. A point-to-multipoint tunnel system, such as an SD-WAN | 2. A point-to-multipoint tunnel system, such as a software-defined | |||
deployment, where the tunnel provider acts as a modem, having | wide-area network (SD-WAN) deployment, where the tunnel provider | |||
knowledge of the characteristics of the underlay network, and | acts as a modem that has knowledge of the characteristics of the | |||
providing that information as availability and metrics between | underlay network and provides that information as availability | |||
tunnel endpoints in the overlay network. | and metrics between tunnel endpoints in the overlay network. | |||
3. A modem that provides connectivity to a remote wide-area 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 | via a wireless link, but the concept of a Layer 2 reachable | |||
remote router does not apply. An example of such a modem would | remote router does not apply. An example of such a modem would | |||
be an LTE device or 802.11 station that provides variable | be an LTE device or 802.11 station that provides variable | |||
connectivity to the Internet. | connectivity to the Internet. | |||
This list of use-cases is not exhaustive, and this extension may well | This list of use cases is not exhaustive, and this extension may well | |||
be applicable to future, currently unforeseen, use-cases. | be applicable to future, currently unforeseen, use cases. | |||
1.3. Requirements | 1.3. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. Operation | 2. Operation | |||
To refer to a Layer 3 DLEP Destination, the DLEP session participant | To refer to a Layer 3 DLEP Destination, the DLEP session participant | |||
adds a Link Identifier Data Item (Section 3.2) to the relevant | adds a Link Identifier Data Item (Section 3.2) to the relevant | |||
Destination Message, and (as usual) includes a MAC Address Data Item. | Destination Message and (as usual) includes a MAC Address Data Item. | |||
When paired with a Link Identifier Data Item, the MAC Address Data | When paired with a Link Identifier Data Item, the MAC Address Data | |||
Item MUST contain the MAC address of the Gateway Node. | Item MUST contain the MAC address of the Gateway Node. | |||
As only modems are initially aware of Layer 3 DLEP Destinations, Link | 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 | 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 | DLEP Destination Up Message from the modem to the router. Once a | |||
link has been identified in this way, Link Identifier Data Items may | link has been identified in this way, Link Identifier Data Items may | |||
be used by either DLEP participant during the lifetime of a DLEP | be used by either DLEP participant during the lifetime of a DLEP | |||
session. Because of this, a router MUST NOT send a DLEP Destination | session. Because of this, a router MUST NOT send a DLEP Destination | |||
Announce Message containing a Link Identifier Data Item referring to | Announce Message containing a Link Identifier Data Item referring to | |||
a link that has not been mentioned in a prior DLEP Destination Up | 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 | Message. If a modem receives such a message, it MUST terminate the | |||
session by issuing a Session Termination Message containing a Status | session by issuing a Session Termination Message containing a Status | |||
Data Item with status code set to 131 'Invalid Destination' and | Data Item with status code set to 131 ('Invalid Destination') and | |||
transition to the Session Termination state. If a router receives a | transition to the Session Termination state. If a router receives a | |||
Destination Up Message specifying a Link Identifier that has already | Destination Up Message specifying a Link Identifier that has already | |||
been used, the router MUST respond with a Destination Up Response | been used, the router MUST respond with a Destination Up Response | |||
Message containing a Status Data Item with status code set to 130 | Message containing a Status Data Item with status code set to 130 | |||
'Invalid Data', and transition to the Session Termination state. | ('Invalid Data') and transition to the Session Termination state. | |||
Because the MAC Address associated with any DLEP Destination Message | Because the MAC address associated with any DLEP Destination Message | |||
containing a Link Identifier Data Item is not the Layer 2 address of | containing a Link Identifier Data Item is not the Layer 2 address of | |||
the final destination, all DLEP Destination Up Messages containing a | the final destination, all DLEP Destination Up Messages containing a | |||
Link Identifier Data Item MUST contain Layer 3 information. In the | Link Identifier Data Item MUST contain Layer 3 information. In the | |||
case of modems that provide Layer 3 wide area network connectivity | case of modems that provide Layer 3 wide area network connectivity | |||
between devices, this means one or more IPv4 or IPv6 Address Data | between devices, this means one or more IPv4 or IPv6 Address Data | |||
Items providing the Layer 3 address of the final destination. When | Items providing the Layer 3 address of the final destination. When | |||
referring to some upstream backbone network infrastructure, this | referring to some upstream backbone network infrastructures, this | |||
means one or more IPv4 or IPv6 Attached Subnet Data Items, for | means one or more IPv4 or IPv6 Attached Subnet Data Items, for | |||
example: '0.0.0.0/0' or '::/0'. This allows the DLEP peer router to | example: '0.0.0.0/0' or '::/0'. This mechanism allows the DLEP peer | |||
understand the properties of the link to those routes. The address | router to understand the properties of the link to those routes. The | |||
or addresses in the IPv4 or IPv6 Address Data Items MUST be the | address or addresses in the IPv4 or IPv6 Address Data Items MUST be | |||
addresses in use on the public side of any Network Address | the addresses in use on the public side of any Network Address | |||
Translation. | Translation. | |||
When the DLEP peer router wishes to route packets to the Layer 3 DLEP | 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 | 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 | used as the Layer 2 destination of the packet if it wishes to use the | |||
the modem network to forward the packet. | modem network to forward the packet. | |||
As routers populate their routing information base with the IP | As routers populate their Routing Information Base with the IP | |||
address of the next hop router towards a destination, implementations | address of the next-hop router towards a destination, implementations | |||
supporting this extension SHOULD announce at least one valid IPv4 or | supporting this extension SHOULD announce at least one valid IPv4 or | |||
IPv6 addresses of the Gateway Node, this removes the need for the | IPv6 addresses of the Gateway Node; this removes the need for the | |||
router to use an additional IP address resolution protocol before | router to use an additional IP address resolution protocol before | |||
adding the route to its routing information base. | adding the route to its Routing Information Base. | |||
2.1. Identifier Restrictions | 2.1. Identifier Restrictions | |||
A Link Identifier is by default 4 octets in length. If a modem | 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 | wishes to use a Link Identifier of a different length, it MUST be | |||
announced using the Link Identifier Length Data Item (Section 3.1) | announced using the Link Identifier Length Data Item (Section 3.1) | |||
contained in the DLEP Session Initialization Response message sent by | contained in the DLEP Session Initialization Response Message sent by | |||
the modem to the router. | the modem to the router. | |||
During the lifetime of a DLEP session, the length of Link Identifiers | During the lifetime of a DLEP session, the length of Link Identifiers | |||
MUST remain constant, i.e. the Length field of the Link Identifier | MUST remain constant, i.e., the Length field of the Link Identifier | |||
Data Item MUST NOT differ between destinations. | Data Item MUST NOT differ between destinations. | |||
The method for generating Link Identifiers is a modem implementation | The method for generating Link Identifiers is a modem implementation | |||
matter and out of scope of this document. Routers must not make any | matter and out of scope of this document. Routers must not make any | |||
assumptions about the meaning of Link Identifiers, or how Link | assumptions about the meaning of Link Identifiers or how Link | |||
Identifiers are generated. | Identifiers are generated. | |||
Within a single DLEP session, all Link Identifiers MUST be unique per | Within a single DLEP session, all Link Identifiers MUST be unique per | |||
MAC Address. This means that a Layer 3 DLEP Destination is uniquely | MAC address. This means that a Layer 3 DLEP Destination is uniquely | |||
identified by the pair: {MAC Address,Link Identifier}. | identified by the pair: {MAC Address,Link Identifier}. | |||
Link Identifiers MUST NOT be reused, i.e. a {MAC Address,Link | 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 | 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 | Destination MUST NOT be used again within the lifetime of a single | |||
DLEP peer-to-peer session. | DLEP peer-to-peer session. | |||
2.2. Negotiation | 2.2. Negotiation | |||
To use this extension, as with all DLEP extensions, the extension | To use this extension, as with all DLEP extensions, the extension | |||
MUST be announced during DLEP session initialization. A router | MUST be announced during DLEP session initialization. A router | |||
advertises support by including the value 'Link Identifiers', TBD1 | advertises support by including the value 3 ('Link Identifiers') | |||
(Section 5), in the Extension Data Item within the Session | (Section 5), in the Extension Data Item within the Session | |||
Initialization Message. A modem advertises support by including the | Initialization Message. A modem advertises support by including the | |||
value 'Link Identifiers' in the Extension Data Item within the | value 3 ('Link Identifiers') in the Extension Data Item within the | |||
Session Initialization Response Message. If both DLEP peers | Session Initialization Response Message. If both DLEP peers | |||
advertise support for this extension then Link Identifier Data Items | advertise support for this extension, then Link Identifier Data Items | |||
can be included in DLEP Messages. | can be included in DLEP Messages. | |||
If a modem requires support for this extension in order to describe | If a modem requires support for this extension in order to describe | |||
destinations, and the router does not advertise support, then the | destinations and the router does not advertise support, then the | |||
modem MUST NOT include a Link Identifier Data Item in any DLEP | modem MUST NOT include a Link Identifier Data Item in any DLEP | |||
Message. However, the modem SHOULD NOT immediately terminate the | Message. However, the modem SHOULD NOT immediately terminate the | |||
DLEP session, rather it SHOULD use a combination of DLEP Session | DLEP session; rather, it SHOULD use a combination of DLEP Session | |||
Messages and DLEP Attached Subnet Data Items to provide general | Messages and DLEP Attached Subnet Data Items to provide general | |||
information. | information. | |||
3. New Data Items | 3. New Data Items | |||
This extension introduces two new DLEP Data Items: the Link | 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 | Identifier Data Item (Section 3.2) used to identify a Layer 3 link at | |||
or beyond a destination, and the Link Identifier Length Data Item | or beyond a destination. | |||
(Section 3.1) used to announce the length of Link Identifiers at | ||||
session initialization. | ||||
3.1. Link Identifier Length Data Item | 3.1. Link Identifier Length Data Item | |||
The Link Identifier Length Data Item is used by a DLEP modem | The Link Identifier Length Data Item is used by a DLEP modem | |||
implementation to specify the length of Link Identifier Data Items. | implementation to specify the length of Link Identifier Data Items. | |||
If the router advertised support by including the value 'Link | If the router advertised support by including the value 3 ('Link | |||
Identifiers' in the Extension Data Item inside the Session | Identifiers') in the Extension Data Item inside the Session | |||
Initialization Message, this data item MAY be used in the Session | Initialization Message, this Data Item MAY be used in the Session | |||
Initialization Response Message, if the specified length is not the | Initialization Response Message if the specified length is not the | |||
default value of 4 octets. If the router did not specify support by | default value of 4 octets. If the router did not specify support by | |||
including the value 'Link Identifiers' in the Extension Data item, | including the value 3 ('Link Identifiers') in the Extension Data | |||
this Data Item MUST NOT be sent. | Item, this Data Item MUST NOT be sent. | |||
0 1 2 3 | 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 | 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 | | | Data Item Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Link Identifier Length | | | Link Identifier Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBD2 (Section 5) | Data Item Type: 26 (see Section 5) | |||
Length: 2 | Length: 2 | |||
Link Identifier Length: The length, in octets, of Link Identifiers | Link Identifier Length: The length, in octets, of Link Identifiers | |||
used by the DLEP modem for this session. | used by the DLEP modem for this session. | |||
A Link Identifier Length Data Item that specifies a Link Identifier | 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. | Length of 4 octets (the default) is valid, even if it has no effect. | |||
3.2. Link Identifier Data Item | 3.2. Link Identifier Data Item | |||
The Link Identifier Data Item MAY be used wherever a MAC Address Data | The Link Identifier Data Item MAY be used wherever a MAC Address Data | |||
Item is defined as usable in core DLEP. | Item is defined as usable in core DLEP [RFC8175]. | |||
0 1 2 3 | 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 | 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 | | | Data Item Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Link Identifier... : | | Link Identifier... : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBD3 (Section 5) | Data Item Type: 27 (see Section 5) | |||
Length: The length of the Data Item, by default 4, but may be | 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 | different if a Link Identifier Length Data Item (Section 3.1) has | |||
been announced during session initialization. | been announced during session initialization. | |||
Link Identifier: The unique identifier of the Layer 3 DLEP | Link Identifier: The unique identifier of the Layer 3 DLEP | |||
Destination. This Link Identifier has no implicit meaning and is | Destination. This Link Identifier has no implicit meaning and is | |||
only used to discriminate between multiple links. | only used to discriminate between multiple links. | |||
4. Security Considerations | 4. Security Considerations | |||
As an extension to the core DLEP protocol, the security | As an extension to core DLEP [RFC8175], the security considerations | |||
considerations of that protocol apply to this extension. This | of that protocol apply to this extension. This extension adds no | |||
extension adds no additional security mechanisms or features. | additional security mechanisms or features. | |||
None of the features introduced by this extension require extra | None of the features introduced by this extension require extra | |||
security consideration by an implementation. | security considerations by an implementation. | |||
5. IANA Considerations | 5. IANA Considerations | |||
Upon approval of this document, IANA is requested to: | 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. | ||||
o Assign a new DLEP Extensions Type Registry value (TBD1) from the | +------+------------------+ | |||
Specification Required section, named "Link Identifiers". | | Code | Description | | |||
+======+==================+ | ||||
| 3 | Link Identifiers | | ||||
+------+------------------+ | ||||
o Assign a new DLEP Data Item Type Values Registry value (TBD2) from | Table 1: Addition to | |||
the Specification Required section, named "Link Identifier | the Extension Type | |||
Length". | Values Registry | |||
o Assign a new DLEP Data Item Type Values Registry value (TBD3) from | IANA has assigned two new values to the "Data Item Type Values" | |||
the Specification Required section, named "Link Identifier". | registry within the "Dynamic Link Exchange Protocol (DLEP) | |||
Parameters" registry. These new values are in the range with the | ||||
"Specification Required" [RFC8126] policy. | ||||
6. Normative References | +-----------+------------------------+ | |||
| 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 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, | |||
RFC2119, March 1997, <https://www.rfc-editor.org/info/ | DOI 10.17487/RFC2119, March 1997, | |||
rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | |||
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, | Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, | |||
DOI 10.17487/RFC8175, June 2017, <https://www.rfc- | DOI 10.17487/RFC8175, June 2017, | |||
editor.org/info/rfc8175>. | <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 | Authors' Addresses | |||
Rick Taylor | Rick Taylor | |||
Airbus Defence & Space | Airbus Defence & Space | |||
Quadrant House | Quadrant House | |||
Celtic Springs | Celtic Springs | |||
Coedkernew | Coedkernew | |||
Newport NP10 8FZ | Newport | |||
UK | NP10 8FZ | |||
United Kingdom | ||||
Email: rick.taylor@airbus.com | Email: rick.taylor@airbus.com | |||
Stan Ratliff | Stan Ratliff | |||
VT iDirect | ||||
13861 Sunrise Valley Drive, Suite 300 | ||||
Herndon, VA 20171 | ||||
USA | ||||
Email: sratliff@idirect.net | ||||
End of changes. 60 change blocks. | ||||
128 lines changed or deleted | 156 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |