draft-ietf-manet-dlep-24.txt   draft-ietf-manet-dlep-25.txt 
Mobile Ad hoc Networks Working Group S. Ratliff Mobile Ad hoc Networks Working Group S. Ratliff
Internet-Draft VT iDirect Internet-Draft VT iDirect
Intended status: Standards Track S. Jury Intended status: Standards Track S. Jury
Expires: January 26, 2017 Cisco Systems Expires: May 1, 2017 Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
R. Taylor R. Taylor
Airbus Defence & Space Airbus Defence & Space
B. Berry B. Berry
July 25, 2016 October 28, 2016
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-24 draft-ietf-manet-dlep-25
Abstract Abstract
When routing devices rely on modems to effect communications over When routing devices rely on modems to effect communications over
wireless links, they need timely and accurate knowledge of the wireless links, they need timely and accurate knowledge of the
characteristics of the link (speed, state, etc.) in order to make characteristics of the link (speed, state, etc.) in order to make
routing decisions. In mobile or other environments where these routing decisions. In mobile or other environments where these
characteristics change frequently, manual configurations or the characteristics change frequently, manual configurations or the
inference of state through routing or transport protocols does not inference of state through routing or transport protocols does not
allow the router to make the best decisions. A bidirectional, event- allow the router to make the best decisions. A bidirectional, event-
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9
4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11
5.2. Session Initialization State . . . . . . . . . . . . . . 12 5.2. Session Initialization State . . . . . . . . . . . . . . 12
5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13
5.4. Session Termination State . . . . . . . . . . . . . . . . 14 5.4. Session Termination State . . . . . . . . . . . . . . . . 14
5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14
5.5.1. Unexpected TCP connection termination . . . . . . . . 14 5.5.1. Unexpected TCP connection termination . . . . . . . . 15
6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15
7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17
9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17
9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18
9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 19
10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19
10.1. General Processing Rules . . . . . . . . . . . . . . . . 19 10.1. General Processing Rules . . . . . . . . . . . . . . . . 19
10.2. Status code processing . . . . . . . . . . . . . . . . . 20 10.2. Status code processing . . . . . . . . . . . . . . . . . 20
10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 20 10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 21
10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21 10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21
10.5. Session Initialization Message . . . . . . . . . . . . . 21 10.5. Session Initialization Message . . . . . . . . . . . . . 22
10.6. Session Initialization Response Message . . . . . . . . 22 10.6. Session Initialization Response Message . . . . . . . . 23
10.7. Session Update Message . . . . . . . . . . . . . . . . . 24 10.7. Session Update Message . . . . . . . . . . . . . . . . . 24
10.8. Session Update Response Message . . . . . . . . . . . . 25 10.8. Session Update Response Message . . . . . . . . . . . . 26
10.9. Session Termination Message . . . . . . . . . . . . . . 25 10.9. Session Termination Message . . . . . . . . . . . . . . 26
10.10. Session Termination Response Message . . . . . . . . . . 25 10.10. Session Termination Response Message . . . . . . . . . . 26
10.11. Destination Up Message . . . . . . . . . . . . . . . . . 26 10.11. Destination Up Message . . . . . . . . . . . . . . . . . 27
10.12. Destination Up Response Message . . . . . . . . . . . . 27 10.12. Destination Up Response Message . . . . . . . . . . . . 28
10.13. Destination Announce Message . . . . . . . . . . . . . . 28 10.13. Destination Announce Message . . . . . . . . . . . . . . 29
10.14. Destination Announce Response Message . . . . . . . . . 28 10.14. Destination Announce Response Message . . . . . . . . . 29
10.15. Destination Down Message . . . . . . . . . . . . . . . . 30 10.15. Destination Down Message . . . . . . . . . . . . . . . . 31
10.16. Destination Down Response Message . . . . . . . . . . . 30 10.16. Destination Down Response Message . . . . . . . . . . . 31
10.17. Destination Update Message . . . . . . . . . . . . . . . 31 10.17. Destination Update Message . . . . . . . . . . . . . . . 31
10.18. Link Characteristics Request Message . . . . . . . . . . 32 10.18. Link Characteristics Request Message . . . . . . . . . . 33
10.19. Link Characteristics Response Message . . . . . . . . . 33 10.19. Link Characteristics Response Message . . . . . . . . . 33
10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34
11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 34 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 37 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 39
11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 38 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 40
11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 39 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 41
11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 40 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 41
11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 41 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 42
11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 41 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 42
11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 42 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 43
11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 43 11.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 44
11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 44 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 45
11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 45 11.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 46
11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 46 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 47
11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 46 11.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 48
11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 47 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48
11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 48 11.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 50
11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50
11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 49 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 51
11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 50 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 52
11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 51 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52
11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 52 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53
12. Security Considerations . . . . . . . . . . . . . . . . . . . 52 11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 54
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 55
13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 53 11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 55
13.2. Signal Type Registration . . . . . . . . . . . . . . . . 53 11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56
13.3. Message Type Registration . . . . . . . . . . . . . . . 53 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57
13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 57
13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 56 13.2. Signal Type Registration . . . . . . . . . . . . . . . . 57
13.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56 13.3. Message Type Registration . . . . . . . . . . . . . . . 58
13.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 57 13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 59
13.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 57 13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 59
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 60
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 60
15.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 61
15.2. Informative References . . . . . . . . . . . . . . . . . 57 13.9. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 61
13.10. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 61
Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 58 13.11. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 62
Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 59 13.12. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 62
B.1. Session Initialization . . . . . . . . . . . . . . . . . 59 13.13. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 62
B.2. Session Initialization - Refused . . . . . . . . . . . . 59 13.14. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 63
B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 60 13.15. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 63
B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 60 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63
B.5. Router Terminates Session . . . . . . . . . . . . . . . . 61 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 61 15.1. Normative References . . . . . . . . . . . . . . . . . . 63
B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 62 15.2. Informative References . . . . . . . . . . . . . . . . . 63
B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 63 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 64
B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 64 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 65
Appendix C. Destination Specific Message Flows . . . . . . . . . 64 B.1. Session Initialization . . . . . . . . . . . . . . . . . 65
C.1. Common Destination Notification . . . . . . . . . . . . . 64 B.2. Session Initialization - Refused . . . . . . . . . . . . 65
C.2. Multicast Destination Notification . . . . . . . . . . . 65 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 66
C.3. Link Characteristics Request . . . . . . . . . . . . . . 66 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 67
B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 67
B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 68
B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 69
B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 70
Appendix C. Destination Specific Message Flows . . . . . . . . . 70
C.1. Common Destination Notification . . . . . . . . . . . . . 70
C.2. Multicast Destination Notification . . . . . . . . . . . 71
C.3. Link Characteristics Request . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction 1. Introduction
There exist today a collection of modem devices that control links of There exist today a collection of modem devices that control links of
variable datarate and quality. Examples of these types of links variable datarate and quality. Examples of these types of links
include line-of-sight (LOS) terrestrial radios, satellite terminals, include line-of-sight (LOS) terrestrial radios, satellite terminals,
and broadband modems. Fluctuations in speed and quality of these and broadband modems. Fluctuations in speed and quality of these
links can occur due to configuration, or on a moment-to-moment basis, links can occur due to configuration, or on a moment-to-moment basis,
due to physical phenomena like multipath interference, obstructions, due to physical phenomena like multipath interference, obstructions,
rain fade, etc. It is also quite possible that link quality and rain fade, etc. It is also quite possible that link quality and
skipping to change at page 9, line 31 skipping to change at page 9, line 31
14, RFC 2119 [RFC2119]. 14, RFC 2119 [RFC2119].
DLEP MUST be implemented on a single Layer 2 domain. The protocol DLEP MUST be implemented on a single Layer 2 domain. The protocol
identifies next-hop destinations by using the MAC address for identifies next-hop destinations by using the MAC address for
delivering data traffic. No manipulation or substitution is delivering data traffic. No manipulation or substitution is
performed; the MAC address supplied in all DLEP Messages is used as performed; the MAC address supplied in all DLEP Messages is used as
the Destination MAC address for frames emitted by the participating the Destination MAC address for frames emitted by the participating
router. MAC addresses MUST be unique within the context of router- router. MAC addresses MUST be unique within the context of router-
modem session. modem session.
To enforce the single Layer 2 domain, implementations MUST support
The Generalized TTL Security Mechanism [RFC5082].
DLEP specifies UDP multicast for single-hop discovery signaling, and DLEP specifies UDP multicast for single-hop discovery signaling, and
TCP for transport of the Messages. Modems and routers participating TCP for transport of the Messages. Modems and routers participating
in DLEP sessions MUST have topologically consistent IP addresses in DLEP sessions MUST have topologically consistent IP addresses
assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6
link-local addresses to reduce the administrative burden of address link-local addresses to reduce the administrative burden of address
assignment. assignment. If the router and modem support both IPv4 and IPv6, the
IPv6 transport MUST be used for the DLEP session.
To enforce the single Layer 2 domain for DLEP Messages, To enforce the single Layer 2 domain for DLEP Messages,
implementations MUST adhere to the Generalized TTL Security Mechanism implementations MUST adhere to the Generalized TTL Security Mechanism
documented in [RFC5082] for all TCP-based DLEP Messages. documented in [RFC5082] for all TCP-based DLEP Messages.
In order to keep the DLEP discovery Signals, which are multicast UDP- In order to keep the DLEP discovery Signals, which are multicast UDP-
based, limited to the same Layer 2 domain, implementations MUST set based, limited to the same Layer 2 domain, implementations MUST set
the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on
receipt of DLEP Signals. Any signal received with a TTL not equal to receipt of DLEP Signals. Any signal received with a TTL not equal to
1 MUST be discarded. 1 MUST be discarded.
skipping to change at page 12, line 5 skipping to change at page 12, line 9
The router implementation then waits for a Peer Offer Signal The router implementation then waits for a Peer Offer Signal
(Section 10.4) response from a potential DLEP modem. While in the (Section 10.4) response from a potential DLEP modem. While in the
Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly
by a DLEP router, at regular intervals. The interval MUST be a by a DLEP router, at regular intervals. The interval MUST be a
minimum of one second; it SHOULD be a configurable parameter. Note minimum of one second; it SHOULD be a configurable parameter. Note
that this operation (sending Peer Discovery and waiting for Peer that this operation (sending Peer Discovery and waiting for Peer
Offer) is outside the DLEP Transaction Model (Section 6), as the Offer) is outside the DLEP Transaction Model (Section 6), as the
Transaction Model only describes Messages on a TCP session. Transaction Model only describes Messages on a TCP session.
Routers MUST use one or more of each of the modem address/port Routers receiving a Peer Offer Signal MUST use one of the modem
combinations from the Peer Offer Signal or, when no Connection Point address/port combinations from the Peer Offer Signal to establish a
Data Items are present, from a priori configuration to establish a TCP connection to the modem, even if a priori configuration exists.
new TCP connection to the modem. If more than one modem address/port If multiple connection point Data Items exist in the received Peer
combinations is provided, router implementations MAY use their own Offer Signal, routers MUST prioritize IPv6 connection points over
heuristics to determine the order in which they are tried. If a TCP IPv4 connection points. If multiple connection points exist with the
connection cannot be achieved using any of the address/port same transport (e.g. IPv6 or IPv4), implementations MAY use their
own heuristics to determine the order in which they are tried. If a
TCP connection cannot be achieved using any of the address/port
combinations and the Discovery mechanism is in use, then the router combinations and the Discovery mechanism is in use, then the router
SHOULD resume issuing Peer Discovery Signals. If no Connection Point SHOULD resume issuing Peer Discovery Signals. If no Connection Point
Data Items are included in the Peer Offer Signal, the router MUST use Data Items are included in the Peer Offer Signal, the router MUST use
the source address of the UDP packet containing the Peer Offer Signal the source address of the UDP packet containing the Peer Offer Signal
as the IP address, and the DLEP well-known port number. as the IP address, and the DLEP well-known port number.
In the Peer Discovery state, the modem implementation MUST listen for In the Peer Discovery state, the modem implementation MUST listen for
incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or
IPv4 link-local multicast address and port. On receipt of a valid IPv4 link-local multicast address and port. On receipt of a valid
Peer Discovery Signal, it MUST reply with a Peer Offer Signal. Peer Discovery Signal, it MUST reply with a Peer Offer Signal.
skipping to change at page 15, line 21 skipping to change at page 15, line 27
receives a request for a destination for which there is already an receives a request for a destination for which there is already an
outstanding request, the implementation MUST terminate the session by outstanding request, the implementation MUST terminate the session by
issuing a Session Termination Message (Section 10.9) containing a issuing a Session Termination Message (Section 10.9) containing a
Status Data Item (Section 11.1) with status code set to 129 Status Data Item (Section 11.1) with status code set to 129
'Unexpected Message', see Table 2, and transition to the Session 'Unexpected Message', see Table 2, and transition to the Session
Termination state. There is no restriction to the total number of Termination state. There is no restriction to the total number of
Message transactions in progress at a time, as long as each Message transactions in progress at a time, as long as each
transaction refers to a different destination. transaction refers to a different destination.
It should be noted that some requests may take a considerable amount It should be noted that some requests may take a considerable amount
of time for some DLEP participants to complete, for example a modem of time for some DLEP participants to complete, for example, a modem
handling a multicast destination up request may have to perform a handling a multicast destination up request may have to perform a
complex network reconfiguration. A sending implementation MUST be complex network reconfiguration. A sending implementation MUST be
able to handle such long running transactions gracefully. able to handle such long running transactions gracefully.
Additionally, only one session request, e.g. a Session Initialization Additionally, only one session request, e.g. a Session Initialization
Message (Section 10.5), may be in progress at a time per session. As Message (Section 10.5), may be in progress at a time per session. As
above, a session transaction is considered complete when a response above, a session transaction is considered complete when a response
matching a previously issued request is received. If a DLEP matching a previously issued request is received. If a DLEP
participant receives a session request while there is already a participant receives a session request while there is already a
session request in progress, it MUST terminate the session by issuing session request in progress, it MUST terminate the session by issuing
skipping to change at page 20, line 10 skipping to change at page 20, line 27
unannounced destination MUST terminate the session by issuing a unannounced destination MUST terminate the session by issuing a
Session Termination Message containing a Status Data Item with status Session Termination Message containing a Status Data Item with status
code set to 131 'Invalid Destination', and transition to the Session code set to 131 'Invalid Destination', and transition to the Session
Termination state. Termination state.
After exchanging Destination Down (Section 10.15) and Destination After exchanging Destination Down (Section 10.15) and Destination
Down Response (Section 10.16) Messages, no Messages concerning a Down Response (Section 10.16) Messages, no Messages concerning a
destination may be a sent until a new Destination Up or Destination destination may be a sent until a new Destination Up or Destination
Announce Message is sent. An implementation receiving a Message Announce Message is sent. An implementation receiving a Message
about a destination previously announced as 'down' MUST terminate the about a destination previously announced as 'down' MUST terminate the
session by issuing a Session Termination Message with a Status Data session by issuing a Session Termination Message containing a Status
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. transition to the Session Termination state.
10.2. Status code processing 10.2. Status code processing
The behaviour of a DLEP participant receiving a Message containing a The behaviour of a DLEP participant receiving a Message containing a
Status Data Item (Section 11.1) is defined by the failure mode Status Data Item (Section 11.1) is defined by the failure mode
associated with the value of the status code field, see Table 2. All associated with the value of the status code field, see Table 2. All
status code values less than 100 have a failure mode of 'Continue', status code values less than 100 have a failure mode of 'Continue',
all other status codes have a failure mode of 'Terminate'. all other status codes have a failure mode of 'Terminate'.
skipping to change at page 22, line 4 skipping to change at page 22, line 23
in the Message Header is set to 1 (see Message Type Registration in the Message Header is set to 1 (see Message Type Registration
(Section 13.3)). (Section 13.3)).
The Session Initialization Message MUST contain a Heartbeat Interval The Session Initialization Message MUST contain a Heartbeat Interval
Data Item (Section 11.5). Data Item (Section 11.5).
The Session Initialization Message MAY contain one of each of the The Session Initialization Message MAY contain one of each of the
following Data Items: following Data Items:
o Peer Type (Section 11.4) o Peer Type (Section 11.4)
o Extensions Supported (Section 11.6) o Extensions Supported (Section 11.6)
The Session Initialization Message MAY contain one or more of each of
the following Data Items, with different values, and the data item
Add flag set to 1:
o IPv4 Address (Section 11.8)
o IPv6 Address (Section 11.9)
o IPv4 Attached Subnet (Section 11.10)
o IPv6 Attached Subnet (Section 11.11)
If any optional extensions are supported by the implementation, they If any optional extensions are supported by the implementation, they
MUST be enumerated in the Extensions Supported Data Item. If an MUST be enumerated in the Extensions Supported Data Item. If an
Extensions Supported Data Item does not exist in a Session Extensions Supported Data Item does not exist in a Session
Initialization Message, the modem MUST conclude that there is no Initialization Message, the modem MUST conclude that there is no
support for extensions in the router. support for extensions in the router.
DLEP Heartbeats are not fully established until receipt of the DLEP Heartbeats are not fully established until receipt of the
Session Initialization Response Message (Section 10.6), and therefore Session Initialization Response Message (Section 10.6), and therefore
implementations MUST use their own timeout and retry heuristics for implementations MUST use their own timeout and retry heuristics for
this Message. this Message.
As an exception to the general rule governing an implementation As an exception to the general rule governing an implementation
receiving an unrecognized Data Item in a Message, see Section 10.1, receiving an unrecognized Data Item in a Message, see Section 10.1,
if a Session Initialization Message contains one or more Extension if a Session Initialization Message contains one or more Extension
Supported Data Items announcing support for extensions that the Supported Data Items announcing support for extensions that the
implementation does not recognize, then the implementation MAY ignore implementation does not recognize, then the implementation MAY ignore
Data Items it does not recognize. Data Items it does not recognize.
10.6. Session Initialization Response Message 10.6. Session Initialization Response Message
A Session Initialization Response Message MUST be sent in response to A Session Initialization Response Message MUST be sent by a DLEP
a received Session Initialization Message (Section 10.5). modem in response to a received Session Initialization Message
(Section 10.5).
To construct a Session Initialization Response Message, the Message To construct a Session Initialization Response Message, the Message
Type value in the Message Header is set to 2 (see Message Type Type value in the Message Header is set to 2 (see Message Type
Registration (Section 13.3)). Registration (Section 13.3)).
The Session Initialization Response Message MUST contain one of each The Session Initialization Response Message MUST contain one of each
of the following Data Items: of the following Data Items:
o Status (Section 11.1) o Status (Section 11.1)
skipping to change at page 23, line 16 skipping to change at page 23, line 46
lifetime of the session: lifetime of the session:
o Resources (Section 11.17) o Resources (Section 11.17)
o Relative Link Quality (Receive) (Section 11.18) o Relative Link Quality (Receive) (Section 11.18)
o Relative Link Quality (Transmit) (Section 11.19) o Relative Link Quality (Transmit) (Section 11.19)
o Maximum Transmission Unit (MTU) (Section 11.20) o Maximum Transmission Unit (MTU) (Section 11.20)
The Session Initialization Response Message MAY contain one of each The Session Initialization Response Message MUST contain an
of the following Data Items: Extensions Supported Data Item (Section 11.6), if DLEP extensions are
supported.
o Peer Type (Section 11.4) The Session Initialization Response Message MAY contain a Peer Type
Data Item (Section 11.4).
o Extensions Supported (Section 11.6) The Session Initialization Response Message MAY contain one or more
of each of the following Data Items, with different values, and the
data item Add flag set to 1:
o IPv4 Address (Section 11.8)
o IPv6 Address (Section 11.9)
o IPv4 Attached Subnet (Section 11.10)
o IPv6 Attached Subnet (Section 11.11)
The Session Initialization Response Message completes the DLEP The Session Initialization Response Message completes the DLEP
session establishment; the modem should transition to the In-Session session establishment; the modem should transition to the In-Session
state when the Message is sent, and the router should transition to state when the Message is sent, and the router should transition to
the In-Session state upon receipt of an acceptable Session the In-Session state upon receipt of an acceptable Session
Initialization Response Message. Initialization Response Message.
All supported metric Data Items MUST be included in the Session All supported metric Data Items MUST be included in the Session
Initialization Response Message, with default values to be used on a Initialization Response Message, with default values to be used on a
session-wide basis. This can be viewed as the modem 'declaring' all session-wide basis. This can be viewed as the modem 'declaring' all
skipping to change at page 24, line 15 skipping to change at page 25, line 5
10.7. Session Update Message 10.7. Session Update Message
A Session Update Message MAY be sent by a DLEP participant to A Session Update Message MAY be sent by a DLEP participant to
indicate local Layer 3 address changes, or metric changes on a indicate local Layer 3 address changes, or metric changes on a
session-wide basis. session-wide basis.
To construct a Session Update Message, the Message Type value in the To construct a Session Update Message, the Message Type value in the
Message Header is set to 3 (see Message Type Registration Message Header is set to 3 (see Message Type Registration
(Section 13.3)). (Section 13.3)).
The Session Update Message MAY contain one of each of the following The Session Update Message MAY contain one or more of each of the
Data Items: following Data Items, with different values:
o IPv4 Address (Section 11.8)
o IPv6 Address (Section 11.9)
o IPv4 Attached Subnet (Section 11.10)
o IPv6 Attached Subnet (Section 11.11)
When sent by a modem, the Session Update Message MAY contain one of
each of the following Data Items:
o Maximum Data Rate (Receive) (Section 11.12) o Maximum Data Rate (Receive) (Section 11.12)
o Maximum Data Rate (Transmit) (Section 11.13) o Maximum Data Rate (Transmit) (Section 11.13)
o Current Data Rate (Receive) (Section 11.14) o Current Data Rate (Receive) (Section 11.14)
o Current Data Rate (Transmit) (Section 11.15) o Current Data Rate (Transmit) (Section 11.15)
o Latency (Section 11.16) o Latency (Section 11.16)
The Session Update Message MAY contain one of each of the following When sent by a modem, the Session Update Message MAY contain one of
Data Items, if the Data Item is in use by the session: each of the following Data Items, if the Data Item is in use by the
session:
o Resources (Section 11.17) o Resources (Section 11.17)
o Relative Link Quality (Receive) (Section 11.18) o Relative Link Quality (Receive) (Section 11.18)
o Relative Link Quality (Transmit) (Section 11.19) o Relative Link Quality (Transmit) (Section 11.19)
o Maximum Transmission Unit (MTU) (Section 11.20) o Maximum Transmission Unit (MTU) (Section 11.20)
The Session Update Message MAY contain one or more of each of the
following Data Items, with different values:
o IPv4 Address (Section 11.8)
o IPv6 Address (Section 11.9)
If metrics are supplied with the Session Update Message (e.g., If metrics are supplied with the Session Update Message (e.g.,
Maximum Data Rate), these metrics are considered to be session-wide, Maximum Data Rate), these metrics are considered to be session-wide,
and therefore MUST be applied to all destinations in the information and therefore MUST be applied to all destinations in the information
base associated with the DLEP session. This includes destinations base associated with the DLEP session. This includes destinations
for which metrics may have been stored based on received Destination for which metrics may have been stored based on received Destination
Update messages. Update messages.
It should be noted that Session Update Messages can be sent by both It should be noted that Session Update Messages can be sent by both
routers and modems. For example, addition of an IPv4 address to the routers and modems. For example, addition of an IPv4 address on the
router MAY prompt a Session Update Message to its attached modems. router MAY prompt a Session Update Message to its attached modems.
Also, for example, a modem that changes its Maximum Data Rate Also, for example, a modem that changes its Maximum Data Rate
(Receive) for all destinations MAY reflect that change via a Session (Receive) for all destinations MAY reflect that change via a Session
Update Message to its attached router(s). Update Message to its attached router(s).
Concerning Layer 3 addresses: If the modem is capable of Concerning Layer 3 addresses and subnets: If the modem is capable of
understanding and forwarding this information (via proprietary understanding and forwarding this information (via mechanisms not
mechanisms), the address update would prompt any remote DLEP modems defined by DLEP), the update would prompt any remote DLEP-enabled
(DLEP-enabled modems in a remote node) to issue a Destination Update modems to issue a Destination Update Message (Section 10.17) to their
Message (Section 10.17) to their local routers with the new (or local routers with the new (or deleted) addresses and subnets.
deleted) addresses. Modems that do not track Layer 3 addresses
SHOULD silently ignore Address Data Items.
10.8. Session Update Response Message 10.8. Session Update Response Message
A Session Update Response Message MUST be sent by a DLEP participant A Session Update Response Message MUST be sent by a DLEP participant
when a Session Update Message (Section 10.7) is received. when a Session Update Message (Section 10.7) is received.
To construct a Session Update Response Message, the Message Type To construct a Session Update Response Message, the Message Type
value in the Message Header is set to 4 (see Message Type value in the Message Header is set to 4 (see Message Type
Registration (Section 13.3)). Registration (Section 13.3)).
skipping to change at page 36, line 19 skipping to change at page 37, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Text... : | Code | Text... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 1 Data Item Type: 1
Length: 1 + Length of text, in octets Length: 1 + Length of text, in octets
Status Code: One of the codes defined in Table 2 below. Status Code: One of the codes defined in Table 2 below.
Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing Text: UTF-8 encoded string of UNICODE [RFC3629] characters,
the cause, used for implementation defined purposes. Since this describing the cause, used for implementation defined purposes.
field is used for description, implementations SHOULD limit Since this field is used for description, implementations SHOULD
characters in this field to printable characters. Implementations limit characters in this field to printable characters.
receiving this Data Item SHOULD check for printable characters in Implementations receiving this Data Item SHOULD check for
the field. printable characters in the field.
An implementation MUST NOT assume the Text field is NUL-terminated. An implementation MUST NOT assume the Text field is NUL-terminated.
+----------+-------------+------------------+-----------------------+ +----------+-------------+------------------+-----------------------+
| Status | Failure | Description | Reason | | Status | Failure | Description | Reason |
| Code | Mode | | | | Code | Mode | | |
+----------+-------------+------------------+-----------------------+ +----------+-------------+------------------+-----------------------+
| 0 | Continue | Success | The Message was | | 0 | Continue | Success | The Message was |
| | | | processed | | | | | processed |
| | | | successfully. | | | | | successfully. |
skipping to change at page 36, line 47 skipping to change at page 37, line 47
| | | | Message subject, e.g. | | | | | Message subject, e.g. |
| | | | in a Destination Up | | | | | in a Destination Up |
| | | | Response Message | | | | | Response Message |
| | | | (Section 10.12) to | | | | | (Section 10.12) to |
| | | | indicate no further | | | | | indicate no further |
| | | | Messages about the | | | | | Messages about the |
| | | | destination. | | | | | destination. |
| 2 | Continue | Request Denied | The receiver refuses | | 2 | Continue | Request Denied | The receiver refuses |
| | | | to complete the | | | | | to complete the |
| | | | request. | | | | | request. |
| 3-111 | Continue | <Reserved> | Reserved for future | | 3 | Continue | Inconsistent | One or more Data |
| | | Data | Items in the Message |
| | | | describe a logically |
| | | | inconsistent state in |
| | | | the network. For |
| | | | example, in the |
| | | | Destination Up |
| | | | Message (Section |
| | | | 10.11) when an |
| | | | announced subnet |
| | | | clashes with an |
| | | | existing destination |
| | | | subnet. |
| 4-111 | Continue | <Reserved> | Reserved for future |
| | | | extensions. | | | | | extensions. |
| 112-127 | Continue | <Private Use> | Available for | | 112-127 | Continue | <Private Use> | Available for |
| | | | experiments. | | | | | experiments. |
| 128 | Terminate | Unknown Message | The Message was not | | 128 | Terminate | Unknown Message | The Message was not |
| | | | recognized by the | | | | | recognized by the |
| | | | implementation. | | | | | implementation. |
| 129 | Terminate | Unexpected | The Message was not | | 129 | Terminate | Unexpected | The Message was not |
| | | Message | expected while the | | | | Message | expected while the |
| | | | device was in the | | | | | device was in the |
| | | | current state, e.g., | | | | | current state, e.g., |
skipping to change at page 38, line 28 skipping to change at page 39, line 38
Flags: Flags field, defined below. Flags: Flags field, defined below.
IPv4 Address: The IPv4 address listening on the modem. IPv4 Address: The IPv4 address listening on the modem.
TCP Port Number: TCP Port number on the modem. TCP Port Number: TCP Port number on the modem.
If the Length field is 7, the port number specified MUST be used to If the Length field is 7, the port number specified MUST be used to
establish the TCP session. If the TCP Port Number is omitted, i.e. establish the TCP session. If the TCP Port Number is omitted, i.e.
the Length field is 5, the router MUST use the DLEP well-known port the Length field is 5, the router MUST use the DLEP well-known port
number (Section 13.7) to establish the TCP connection. number (Section 13.13) to establish the TCP connection.
The Flags field is defined as: The Flags field is defined as:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
skipping to change at page 39, line 34 skipping to change at page 40, line 43
Flags: Flags field, defined below. Flags: Flags field, defined below.
IPv6 Address: The IPv6 address listening on the modem. IPv6 Address: The IPv6 address listening on the modem.
TCP Port Number: TCP Port number on the modem. TCP Port Number: TCP Port number on the modem.
If the Length field is 19, the port number specified MUST be used to If the Length field is 19, the port number specified MUST be used to
establish the TCP session. If the TCP Port Number is omitted, i.e. establish the TCP session. If the TCP Port Number is omitted, i.e.
the Length field is 17, the router MUST use the DLEP well-known port the Length field is 17, the router MUST use the DLEP well-known port
number (Section 13.7) to establish the TCP connection. number (Section 13.13) to establish the TCP connection.
The Flags field is defined as: The Flags field is defined as:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
skipping to change at page 40, line 19 skipping to change at page 41, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length | | Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type... : | Peer Type... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 4 Data Item Type: 4
Length: Length of Peer Type string, in octets. Length: Length of Peer Type string, in octets.
Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For Peer Type: UTF-8 encoded string of UNICODE [RFC3629] characters.
example, a satellite modem might set this variable to "Satellite For example, a satellite modem might set this variable to
terminal". Since this Data Item is intended to provide additional "Satellite terminal". Since this Data Item is intended to provide
information for display commands, sending implementations SHOULD additional information for display commands, sending
limit the data to printable characters, and receiving implementations SHOULD limit the data to printable characters, and
implementations SHOULD check the data for printable characters. receiving implementations SHOULD check the data for printable
characters.
An implementation MUST NOT assume the Peer Type field is NUL- An implementation MUST NOT assume the Peer Type field is NUL-
terminated. terminated.
11.5. Heartbeat Interval 11.5. Heartbeat Interval
The Heartbeat Interval Data Item is used to specify a period in The Heartbeat Interval Data Item is used to specify a period in
milliseconds for Heartbeat Messages (Section 10.20). milliseconds for Heartbeat Messages (Section 10.20).
The Heartbeat Interval Data Item contains the following fields: The Heartbeat Interval Data Item contains the following fields:
skipping to change at page 41, line 21 skipping to change at page 42, line 26
Each Extension Type definition includes which additional Signals and Each Extension Type definition includes which additional Signals and
Data Items are supported. Data Items are supported.
The Extensions Supported Data Item contains the following fields: The Extensions Supported Data Item contains the following fields:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List... | Extensions List... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 6 Data Item Type: 6
Length: Length of the extensions list in octets. This is twice (2x) Length: Length of the extensions list in octets. This is twice (2x)
the number of extensions. the number of extensions.
Extension List: A list of extensions supported, identified by their Extension List: A list of extensions supported, identified by their
2-octet value as listed in the extensions registry. 2-octet value as listed in the extensions registry.
skipping to change at page 42, line 25 skipping to change at page 43, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 7 Data Item Type: 7
Length: 6 for EUI-48 format, or 8 for EUI-64 format Length: 6 for EUI-48 format, or 8 for EUI-64 format
MAC Address: MAC Address of the destination. MAC Address: MAC Address of the destination.
11.8. IPv4 Address 11.8. IPv4 Address
When included in Destination Messages, this Data Item contains the When included in the Session Update Message, this Data Item contains
IPv4 address of the destination. When included in the Session Update the IPv4 address of the peer. When included in Destination Messages,
Message, this Data Item contains the IPv4 address of the peer. In this Data Item contains the IPv4 address of the destination. In
either case, the Data Item also contains an indication of whether either case, the Data Item also contains an indication of whether
this is a new or existing address, or is a deletion of a previously this is a new or existing address, or is a deletion of a previously
known address. known address.
The IPv4 Address Data Item contains the following fields: The IPv4 Address Data Item contains the following fields:
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 |
skipping to change at page 43, line 15 skipping to change at page 44, line 15
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |A| | Reserved |A|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing A: Add/Drop flag, indicating whether this is a new or existing
address (1), or a withdrawal of an address (0). address (1), or a withdrawal of an address (0).
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
11.8.1. IPv4 Address Processing
Processing of the IPv4 Address Data Item MUST be done within the
context of the DLEP Peer session on which it is presented.
The handling of erroneous or logically inconsistent conditions
depends upon the type of the message that contains the data item:
If the containing message is a Session Message, e.g., Session
Initialization Message (Section 10.5), or Session Update Message
(Section 10.7), the receiver of inconsistent information MUST issue a
Session Termination Message (Section 10.9) containing a Status Data
Item (Section 11.1) with status code set to 130 'Invalid Data', and
transition to the Session Termination state. Examples of such
conditions are:
o An address Drop operation referencing an address that is not
associated with the peer in the current session.
o An address Add operation referencing an address that has already
been added to the peer in the current session.
If the containing message is a Destination Message, e.g., Destination
Up Message (Section 10.11), or Destination Update Message
(Section 10.17), the receiver of inconsistent information MAY issue
the appropriate response message containing a Status Data Item, with
status code set to 3 'Inconsistent Data', but MUST continue with
session processing. Examples of such conditions are:
o An address Add operation referencing an address that has already
been added to the destination in the current session.
o An address Add operation referencing an address that is associated
with a different destination or the peer in the current session
o An address Drop operation referencing an address that is not
associated with the destination in the current session.
If no response message is appropriate, for example, the Destination
Update Message, then the implementation MUST continue with session
processing.
Modems that do not track IPv4 addresses MUST silently ignore IPv4
Address Data Items.
11.9. IPv6 Address 11.9. IPv6 Address
When included in Destination Messages, this Data Item contains the When included in the Session Update Message, this Data Item contains
IPv6 address of the destination. When included in the Session Update the IPv6 address of the peer. When included in Destination Messages,
Message, this Data Item contains the IPv6 address of the peer. In this Data Item contains the IPv6 address of the destination. In
either case, the Data Item also contains an indication of whether either case, the Data Item also contains an indication of whether
this is a new or existing address, or is a deletion of a previously this is a new or existing address, or is a deletion of a previously
known address. known address.
The IPv6 Address Data Item contains the following fields: The IPv6 Address Data Item contains the following fields:
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 |
skipping to change at page 44, line 9 skipping to change at page 46, line 4
Flags: Flags field, defined below. Flags: Flags field, defined below.
IPv6 Address: IPv6 Address of the destination or peer. IPv6 Address: IPv6 Address of the destination or peer.
The Flags field is defined as: The Flags field is defined as:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |A| | Reserved |A|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing A: Add/Drop flag, indicating whether this is a new or existing
address (1), or a withdrawal of an address (0). address (1), or a withdrawal of an address (0).
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
11.9.1. IPv6 Address Processing
Processing of the IPv6 Address Data Item MUST be done within the
context of the DLEP Peer session on which it is presented.
The handling of erroneous or logically inconsistent conditions
depends upon the type of the message that contains the data item:
If the containing message is a Session Message, e.g., Session
Initialization Message (Section 10.5), or Session Update Message
(Section 10.7), the receiver of inconsistent information MUST issue a
Session Termination Message (Section 10.9) containing a Status Data
Item (Section 11.1) with status code set to 130 'Invalid Data', and
transition to the Session Termination state. Examples of such
conditions are:
o An address Drop operation referencing an address that is not
associated with the peer in the current session.
o An address Add operation referencing an address that has already
been added to the peer in the current session.
If the containing message is a Destination Message, e.g., Destination
Up Message (Section 10.11), or Destination Update Message
(Section 10.17), the receiver of inconsistent information MAY issue
the appropriate response message containing a Status Data Item, with
status code set to 3 'Inconsistent Data', but MUST continue with
session processing. Examples of such conditions are:
o An address Add operation referencing an address that has already
been added to the destination in the current session.
o An address Add operation referencing an address that is associated
with a different destination or the peer in the current session
o An address Drop operation referencing an address that is not
associated with the destination in the current session.
If no response message is appropriate, for example, the Destination
Update Message, then the implementation MUST continue with session
processing.
Modems that do not track IPv6 addresses MUST silently ignore IPv6
Address Data Items.
11.10. IPv4 Attached Subnet 11.10. IPv4 Attached Subnet
The DLEP IPv4 Attached Subnet allows a device to declare that it has The DLEP IPv4 Attached Subnet allows a device to declare that it has
an IPv4 subnet (e.g., a stub network) attached, that it has become an IPv4 subnet (e.g., a stub network) attached, that it has become
aware of an IPv4 subnet being present at a remote destination, or aware of an IPv4 subnet being present at a remote destination, or
that it has become aware of the loss of a subnet at the remote that it has become aware of the loss of a subnet at the remote
destination. destination.
The DLEP IPv4 Attached Subnet Data Item contains the following The DLEP IPv4 Attached Subnet Data Item contains the following
fields: fields:
skipping to change at page 45, line 15 skipping to change at page 48, line 5
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |A| | Reserved |A|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing subnet A: Add/Drop flag, indicating whether this is a new or existing subnet
address (1), or a withdrawal of a subnet address (0). address (1), or a withdrawal of a subnet address (0).
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
11.10.1. IPv4 Attached Subnet Processing
Processing of the IPv4 Attached Subnet Data Item MUST be done within
the context of the DLEP Peer session on which it is presented.
If the containing message is a Session Message, e.g., Session
Initialization Message (Section 10.5), or Session Update Message
(Section 10.7), the receiver of inconsistent information MUST issue a
Session Termination Message (Section 10.9) containing a Status Data
Item (Section 11.1) with status code set to 130 'Invalid Data', and
transition to the Session Termination state. Examples of such
conditions are:
o A subnet Drop operation referencing a subnet that is not
associated with the peer in the current session.
o A subnet Add operation referencing a subnet that has already been
added to the peer in the current session.
If the containing message is a Destination Message, e.g., Destination
Up Message (Section 10.11), or Destination Update Message
(Section 10.17), the receiver of inconsistent information MAY issue
the appropriate response message containing a Status Data Item, with
status code set to 3 'Inconsistent Data', but MUST continue with
session processing. Examples of such conditions are:
o A subnet Add operation referencing a subnet that has already been
added to the destination in the current session.
o A subnet Add operation referencing a subnet that is associated
with a different destination in the current session.
o A subnet Drop operation referencing a subnet that is not
associated with the destination in the current session.
If no response message is appropriate, for example, the Destination
Update Message, then the implementation MUST continue with session
processing.
Modems that do not track IPv4 subnets MUST silently ignore IPv4
Attached Subnet Data Items.
11.11. IPv6 Attached Subnet 11.11. IPv6 Attached Subnet
The DLEP IPv6 Attached Subnet allows a device to declare that it has The DLEP IPv6 Attached Subnet allows a device to declare that it has
an IPv6 subnet (e.g., a stub network) attached, that it has become an IPv6 subnet (e.g., a stub network) attached, that it has become
aware of an IPv6 subnet being present at a remote destination, or aware of an IPv6 subnet being present at a remote destination, or
that it has become aware of the loss of a subnet at the remote that it has become aware of the loss of a subnet at the remote
destination. destination.
The DLEP IPv6 Attached Subnet Data Item contains the following The DLEP IPv6 Attached Subnet Data Item contains the following
fields: fields:
skipping to change at page 46, line 17 skipping to change at page 50, line 5
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |A| | Reserved |A|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing subnet A: Add/Drop flag, indicating whether this is a new or existing subnet
address (1), or a withdrawal of a subnet address (0). address (1), or a withdrawal of a subnet address (0).
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
11.11.1. IPv6 Attached Subnet Processing
Processing of the IPv6 Attached Subnet Data Item MUST be done within
the context of the DLEP Peer session on which it is presented.
If the containing message is a Session Message, e.g., Session
Initialization Message (Section 10.5), or Session Update Message
(Section 10.7), the receiver of inconsistent information MUST issue a
Session Termination Message (Section 10.9) containing a Status Data
Item (Section 11.1) with status code set to 130 'Invalid Data', and
transition to the Session Termination state. Examples of such
conditions are:
o A subnet Drop operation referencing a subnet that is not
associated with the peer in the current session.
o A subnet Add operation referencing a subnet that has already been
added to the peer in the current session.
If the containing message is a Destination Message, e.g., Destination
Up Message (Section 10.11), or Destination Update Message
(Section 10.17), the receiver of inconsistent information MAY issue
the appropriate response message containing a Status Data Item, with
status code set to 3 'Inconsistent Data', but MUST continue with
session processing. Examples of such conditions are:
o A subnet Add operation referencing a subnet that has already been
added to the destination in the current session.
o A subnet Add operation referencing a subnet that is associated
with a different destination in the current session.
o A subnet Drop operation referencing a subnet that is not
associated with the destination in the current session.
If no response message is appropriate, for example, the Destination
Update Message, then the implementation MUST continue with session
processing.
Modems that do not track IPv6 subnets MUST silently ignore IPv4
Attached Subnet Data Items.
11.12. Maximum Data Rate (Receive) 11.12. Maximum Data Rate (Receive)
The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate
the maximum theoretical data rate, in bits per second, that can be the maximum theoretical data rate, in bits per second, that can be
achieved while receiving data on the link. achieved while receiving data on the link.
The Maximum Data Rate (Receive) Data Item contains the following The Maximum Data Rate (Receive) Data Item contains the following
fields: fields:
0 1 2 3 0 1 2 3
skipping to change at page 53, line 17 skipping to change at page 57, line 38
information base of hosts that persistently fail Session information base of hosts that persistently fail Session
Initialization having provided an acceptable Peer Discovery Signal, Initialization having provided an acceptable Peer Discovery Signal,
and ignore subsequent Peer Discovery Signals from such hosts. and ignore subsequent Peer Discovery Signals from such hosts.
This specification does not address security of the data plane, as it This specification does not address security of the data plane, as it
(the data plane) is not affected, and standard security procedures (the data plane) is not affected, and standard security procedures
can be employed. can be employed.
13. IANA Considerations 13. IANA Considerations
This section specifies requests to IANA.
13.1. Registrations 13.1. Registrations
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
protocol registry for Dynamic Link Exchange Protocol (DLEP). The protocol registry for Dynamic Link Exchange Protocol (DLEP). The
remainder of this section requests the creation of new DLEP specific remainder of this section requests the creation of new DLEP specific
registries. registries.
13.2. Signal Type Registration 13.2. Signal Type Registration
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
skipping to change at page 56, line 11 skipping to change at page 60, line 11
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+--------------+---------------+-------------------------+ +--------------+---------------+-------------------------+
| Status Code | Failure Mode | Description/Policy | | Status Code | Failure Mode | Description/Policy |
+--------------+---------------+-------------------------+ +--------------+---------------+-------------------------+
| 0 | Continue | Success | | 0 | Continue | Success |
| 1 | Continue | Not Interested | | 1 | Continue | Not Interested |
| 2 | Continue | Request Denied | | 2 | Continue | Request Denied |
| 3-111 | Continue | Specification Required | | 3 | Continue | Inconsistent Data |
| 4-111 | Continue | Specification Required |
| 112-127 | Continue | Private Use | | 112-127 | Continue | Private Use |
| 128 | Terminate | Unknown Message | | 128 | Terminate | Unknown Message |
| 129 | Terminate | Unexpected Message | | 129 | Terminate | Unexpected Message |
| 130 | Terminate | Invalid Data | | 130 | Terminate | Invalid Data |
| 131 | Terminate | Invalid Destination | | 131 | Terminate | Invalid Destination |
| 132 | Terminate | Timed Out | | 132 | Terminate | Timed Out |
| 133-239 | Terminate | Specification Required | | 133-239 | Terminate | Specification Required |
| 240-254 | Terminate | Private Use | | 240-254 | Terminate | Private Use |
| 255 | Terminate | Reserved | | 255 | Terminate | Reserved |
+--------------+---------------+-------------------------+ +--------------+---------------+-------------------------+
skipping to change at page 56, line 43 skipping to change at page 60, line 44
+--------------+----------------------------+ +--------------+----------------------------+
| 0 | Reserved | | 0 | Reserved |
| 1 | Credit Windowing [CREDIT] | | 1 | Credit Windowing [CREDIT] |
| 2-65519 | Specification Required | | 2-65519 | Specification Required |
| 65520-65534 | Private Use | | 65520-65534 | Private Use |
| 65535 | Reserved | | 65535 | Reserved |
+--------------+----------------------------+ +--------------+----------------------------+
Table 3: DLEP Extension types Table 3: DLEP Extension types
13.7. DLEP Well-known Port 13.7. DLEP IPv4 Connection Point Flags
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv4 Connection Point Flags".
The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+
| Bit | Description/Policy |
+------------+----------------------------------+
| 0-7 | Reserved/Specification Required |
+------------+----------------------------------+
13.8. DLEP IPv6 Connection Point Flags
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv6 Connection Point Flags".
The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+
| Bit | Description/Policy |
+------------+----------------------------------+
| 0-7 | Reserved/Specification Required |
+------------+----------------------------------+
13.9. DLEP IPv4 Address Flag
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv4 Address Flags".
The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+
| Bit | Description/Policy |
+------------+----------------------------------+
| 0-6 | Reserved/Specification Required |
| 7 | Add/Drop indicator |
+------------+----------------------------------+
13.10. DLEP IPv6 Address Flag
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv6 Address Flags".
The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+
| Bit | Description/Policy |
+------------+----------------------------------+
| 0-6 | Reserved/Specification Required |
| 7 | Add/Drop indicator |
+------------+----------------------------------+
13.11. DLEP IPv4 Attached Subnet Flag
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv4 Attached Subnet Flags".
The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+
| Bit | Description/Policy |
+------------+----------------------------------+
| 0-6 | Reserved/Specification Required |
| 7 | Add/Drop indicator |
+------------+----------------------------------+
13.12. DLEP IPv6 Attached Subnet Flag
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv6 Attached Subnet Flags".
The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+
| Bit | Description/Policy |
+------------+----------------------------------+
| 0-6 | Reserved/Specification Required |
| 7 | Add/Drop indicator |
+------------+----------------------------------+
13.13. DLEP Well-known Port
Upon approval of this document, IANA is requested to assign a single Upon approval of this document, IANA is requested to assign a single
value in the "Service Name and Transport Protocol Port Number value in the "Service Name and Transport Protocol Port Number
Registry" found at https://www.iana.org/assignments/service-names- Registry" found at https://www.iana.org/assignments/service-names-
port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as
defined in this document. This assignment should be valid for TCP defined in this document. This assignment should be valid for TCP
and UDP. and UDP.
13.8. DLEP IPv4 Link-local Multicast Address 13.14. DLEP IPv4 Link-local Multicast Address
Upon approval of this document, IANA is requested to assign an IPv4 Upon approval of this document, IANA is requested to assign an IPv4
multicast address registry found at http://www.iana.org/assignments/ multicast address registry found at http://www.iana.org/assignments/
multicast-addresses for use as the "IPv4 DLEP Discovery Address". multicast-addresses for use as the "IPv4 DLEP Discovery Address".
13.9. DLEP IPv6 Link-local Multicast Address 13.15. DLEP IPv6 Link-local Multicast Address
Upon approval of this document, IANA is requested to assign an IPv6 Upon approval of this document, IANA is requested to assign an IPv6
multicast address registry found at http://www.iana.org/assignments/ multicast address registry found at http://www.iana.org/assignments/
multicast-addresses for use as the "IPv6 DLEP Discovery Address". multicast-addresses for use as the "IPv6 DLEP Discovery Address".
14. Acknowledgements 14. Acknowledgements
We would like to acknowledge and thank the members of the DLEP design We would like to acknowledge and thank the members of the DLEP design
team, who have provided invaluable insight. The members of the team, who have provided invaluable insight. The members of the
design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning
skipping to change at page 57, line 37 skipping to change at page 63, line 37
15. References 15. References
15.1. Normative References 15.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<http://www.rfc-editor.org/info/rfc5082>. <http://www.rfc-editor.org/info/rfc5082>.
[UNIV8] "The Unicode Consortium. The Unicode Standard, Version
8.0.0, (Mountain View, CA: The Unicode Consortium, 2015.
ISBN 978-1-936213-10-8)",
http://www.unicode.org/versions/Unicode8.0.0/, June 2015.
15.2. Informative References 15.2. Informative References
[CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF
draft draft-ietf-manet-credit-window-04, March 2016. draft draft-ietf-manet-credit-window-04, March 2016.
[IEEE-802.1AE] [IEEE-802.1AE]
"IEEE Standards for Local and Metropolitan Area Networks: "IEEE Standards for Local and Metropolitan Area Networks:
Media Access Control (MAC) Security", Media Access Control (MAC) Security",
DOI 10.1109/IEEESTD.2006.245590, August 2006. DOI 10.1109/IEEESTD.2006.245590, August 2006.
 End of changes. 49 change blocks. 
144 lines changed or deleted 461 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/