draft-ietf-manet-dlep-10.txt   draft-ietf-manet-dlep-11.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 B. Berry Intended status: Standards Track B. Berry
Expires: November 6, 2015 Expires: November 11, 2015
S. Jury S. Jury
Cisco Systems Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
R. Taylor R. Taylor
Airbus Defence & Space Airbus Defence & Space
May 5, 2015 May 10, 2015
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-10 draft-ietf-manet-dlep-11
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
forwarding decisions. In mobile or other environments where these forwarding 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 45
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 November 6, 2015. This Internet-Draft will expire on November 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 36 skipping to change at page 2, line 36
3. Core Features and Optional Extensions . . . . . . . . . . . . 10 3. Core Features and Optional Extensions . . . . . . . . . . . . 10
3.1. Negotiation of Optional Extensions . . . . . . . . . . . 10 3.1. Negotiation of Optional Extensions . . . . . . . . . . . 10
3.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 11 3.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 11
3.3. Experimental Signals and Data Items . . . . . . . . . . . 11 3.3. Experimental Signals and Data Items . . . . . . . . . . . 11
4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Mandatory Metrics . . . . . . . . . . . . . . . . . . . . 12 4.1. Mandatory Metrics . . . . . . . . . . . . . . . . . . . . 12
5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 12 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 12
5.1. DLEP Router session flow - Discovery case . . . . . . . . 13 5.1. DLEP Router session flow - Discovery case . . . . . . . . 13
5.2. DLEP Router session flow - Configured case . . . . . . . 13 5.2. DLEP Router session flow - Configured case . . . . . . . 13
5.3. DLEP Modem session flow . . . . . . . . . . . . . . . . . 14 5.3. DLEP Modem session flow . . . . . . . . . . . . . . . . . 14
5.4. Common Session Flow . . . . . . . . . . . . . . . . . . . 14 5.4. Common Session Flow . . . . . . . . . . . . . . . . . . . 15
6. DLEP Message Processing . . . . . . . . . . . . . . . . . . . 16 6. DLEP Signal Processing . . . . . . . . . . . . . . . . . . . 16
6.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 16 6.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 16
6.2. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 17 6.2. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 17
7. DLEP Signals . . . . . . . . . . . . . . . . . . . . . . . . 17 7. DLEP Signals . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 18 7.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 18
7.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 18 7.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 19
7.3. Peer Initialization Signal . . . . . . . . . . . . . . . 19 7.3. Peer Initialization Signal . . . . . . . . . . . . . . . 19
7.4. Peer Initialization ACK Signal . . . . . . . . . . . . . 20 7.4. Peer Initialization ACK Signal . . . . . . . . . . . . . 20
7.5. Peer Update Signal . . . . . . . . . . . . . . . . . . . 22 7.5. Peer Update Signal . . . . . . . . . . . . . . . . . . . 22
7.6. Peer Update ACK Signal . . . . . . . . . . . . . . . . . 23 7.6. Peer Update ACK Signal . . . . . . . . . . . . . . . . . 23
7.7. Peer Termination Signal . . . . . . . . . . . . . . . . . 24 7.7. Peer Termination Signal . . . . . . . . . . . . . . . . . 24
7.8. Peer Termination ACK Signal . . . . . . . . . . . . . . . 24 7.8. Peer Termination ACK Signal . . . . . . . . . . . . . . . 25
7.9. Destination Up Signal . . . . . . . . . . . . . . . . . . 25 7.9. Destination Up Signal . . . . . . . . . . . . . . . . . . 25
7.10. Destination Up ACK Signal . . . . . . . . . . . . . . . . 26 7.10. Destination Up ACK Signal . . . . . . . . . . . . . . . . 26
7.11. Destination Down Signal . . . . . . . . . . . . . . . . . 27 7.11. Destination Down Signal . . . . . . . . . . . . . . . . . 27
7.12. Destination Down ACK Signal . . . . . . . . . . . . . . . 27 7.12. Destination Down ACK Signal . . . . . . . . . . . . . . . 27
7.13. Destination Update Signal . . . . . . . . . . . . . . . . 28 7.13. Destination Update Signal . . . . . . . . . . . . . . . . 28
7.14. Heartbeat Signal . . . . . . . . . . . . . . . . . . . . 29 7.14. Heartbeat Signal . . . . . . . . . . . . . . . . . . . . 29
7.15. Link Characteristics Request Signal . . . . . . . . . . . 29 7.15. Link Characteristics Request Signal . . . . . . . . . . . 29
7.16. Link Characteristics ACK Signal . . . . . . . . . . . . . 30 7.16. Link Characteristics ACK Signal . . . . . . . . . . . . . 30
8. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 31 8. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. DLEP Version . . . . . . . . . . . . . . . . . . . . . . 32 8.1. DLEP Version . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. IPv4 Connection Point . . . . . . . . . . . . . . . . . . 34 8.3. IPv4 Connection Point . . . . . . . . . . . . . . . . . . 34
8.4. IPv6 Connection Point . . . . . . . . . . . . . . . . . . 35 8.4. IPv6 Connection Point . . . . . . . . . . . . . . . . . . 35
8.5. Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 36 8.5. Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 36
8.6. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 36 8.6. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 36
8.7. Extensions Supported . . . . . . . . . . . . . . . . . . 37 8.7. Extensions Supported . . . . . . . . . . . . . . . . . . 37
8.8. Experimental Definition . . . . . . . . . . . . . . . . . 37 8.8. Experimental Definition . . . . . . . . . . . . . . . . . 38
8.9. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 38 8.9. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 38
8.10. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 39 8.10. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 39
8.11. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 39 8.11. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 40
8.12. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 40 8.12. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 40
8.13. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 41 8.13. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 41
8.14. Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 41 8.14. Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 42
8.15. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 42 8.15. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 42
8.16. Current Data Rate (Receive) . . . . . . . . . . . . . . . 43 8.16. Current Data Rate (Receive) . . . . . . . . . . . . . . . 43
8.17. Current Data Rate (Transmit) . . . . . . . . . . . . . . 43 8.17. Current Data Rate (Transmit) . . . . . . . . . . . . . . 44
8.18. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.18. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.19. Resources (Receive) . . . . . . . . . . . . . . . . . . . 45 8.19. Resources (Receive) . . . . . . . . . . . . . . . . . . . 45
8.20. Resources (Transmit) . . . . . . . . . . . . . . . . . . 46 8.20. Resources (Transmit) . . . . . . . . . . . . . . . . . . 46
8.21. Relative Link Quality (Receive) . . . . . . . . . . . . . 46 8.21. Relative Link Quality (Receive) . . . . . . . . . . . . . 47
8.22. Relative Link Quality (Transmit) . . . . . . . . . . . . 47 8.22. Relative Link Quality (Transmit) . . . . . . . . . . . . 47
8.23. Link Characteristics ACK Timer . . . . . . . . . . . . . 47 8.23. Link Characteristics ACK Timer . . . . . . . . . . . . . 48
9. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 48 9. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Credit-Windowing Signals . . . . . . . . . . . . . . . . 48 9.1. Credit-Windowing Signals . . . . . . . . . . . . . . . . 49
9.1.1. Destination Up Signal . . . . . . . . . . . . . . . . 49 9.1.1. Destination Up Signal . . . . . . . . . . . . . . . . 49
9.1.2. Destination Up ACK Signal . . . . . . . . . . . . . . 49 9.1.2. Destination Up ACK Signal . . . . . . . . . . . . . . 49
9.1.3. Destination Update Signal . . . . . . . . . . . . . . 49 9.1.3. Destination Update Signal . . . . . . . . . . . . . . 49
9.2. Credit-Windowing Data Items . . . . . . . . . . . . . . . 49 9.2. Credit-Windowing Data Items . . . . . . . . . . . . . . . 50
9.2.1. Credit Grant . . . . . . . . . . . . . . . . . . . . 50 9.2.1. Credit Grant . . . . . . . . . . . . . . . . . . . . 50
9.2.2. Credit Window Status . . . . . . . . . . . . . . . . 51 9.2.2. Credit Window Status . . . . . . . . . . . . . . . . 51
9.2.3. Credit Request . . . . . . . . . . . . . . . . . . . 51 9.2.3. Credit Request . . . . . . . . . . . . . . . . . . . 52
10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 52 11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 53
11.2. Expert Review: Evaluation Guidelines . . . . . . . . . . 53 11.2. Expert Review: Evaluation Guidelines . . . . . . . . . . 53
11.3. Signal Type Registration . . . . . . . . . . . . . . . . 53 11.3. Signal Type Registration . . . . . . . . . . . . . . . . 53
11.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54 11.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54
11.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55 11.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55
11.6. DLEP Extensions Registrations . . . . . . . . . . . . . 55 11.6. DLEP Extensions Registrations . . . . . . . . . . . . . 56
11.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56 11.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56
11.8. DLEP Multicast Address . . . . . . . . . . . . . . . . . 56 11.8. DLEP Multicast Address . . . . . . . . . . . . . . . . . 56
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 56 13.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 56 Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 57
A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 56 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2. Session Initialization . . . . . . . . . . . . . . . . . 57 A.2. Session Initialization . . . . . . . . . . . . . . . . . 57
A.3. Session Initialization - Refused . . . . . . . . . . . . 58 A.3. Session Initialization - Refused . . . . . . . . . . . . 58
A.4. Router Changes IP Addresses . . . . . . . . . . . . . . . 58 A.4. Router Changes IP Addresses . . . . . . . . . . . . . . . 59
A.5. Modem Changes Session-wide Metrics . . . . . . . . . . . 58 A.5. Modem Changes Session-wide Metrics . . . . . . . . . . . 59
A.6. Router Terminates Session . . . . . . . . . . . . . . . . 59 A.6. Router Terminates Session . . . . . . . . . . . . . . . . 59
A.7. Modem Terminates Session . . . . . . . . . . . . . . . . 59 A.7. Modem Terminates Session . . . . . . . . . . . . . . . . 60
A.8. Session Heartbeats . . . . . . . . . . . . . . . . . . . 60 A.8. Session Heartbeats . . . . . . . . . . . . . . . . . . . 60
A.9. Router Detects a Heartbeat timeout . . . . . . . . . . . 61 A.9. Router Detects a Heartbeat timeout . . . . . . . . . . . 61
A.10. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 62 A.10. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 62
Appendix B. Destination Specific Signal Flows . . . . . . . . . 62 Appendix B. Destination Specific Signal Flows . . . . . . . . . 62
B.1. Common Destination Signaling . . . . . . . . . . . . . . 62 B.1. Common Destination Signaling . . . . . . . . . . . . . . 62
B.2. Multicast Destination Signaling . . . . . . . . . . . . . 63 B.2. Multicast Destination Signaling . . . . . . . . . . . . . 63
B.3. Link Characteristics Request . . . . . . . . . . . . . . 63 B.3. Link Characteristics Request . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
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 cable/DSL modems. Fluctuations in speed and quality of these and cable/DSL modems. Fluctuations in speed and quality of these
links can occur due to configuration (in the case of cable/DSL links can occur due to configuration, or on a moment-to-moment basis,
modems), or on a moment-to-moment basis, due to physical phenomena due to physical phenomena like multipath interference, obstructions,
like multipath interference, obstructions, rain fade, etc. It is rain fade, etc. It is also quite possible that link quality and
also quite possible that link quality and datarate varies with datarate varies with respect to individual destinations on a link,
respect to individual destinations on a link, and with the type of and with the type of traffic being sent. As an example, consider the
traffic being sent. As an example, consider the case of an 802.11g case of an 802.11g access point, serving 2 associated laptop
access point, serving 2 associated laptop computers. In this computers. In this environment, the answer to the question "What is
environment, the answer to the question "What is the datarate on the the datarate on the 802.11g link?" is "It depends on which associated
802.11g link?" is "It depends on which associated laptop we're laptop we're talking about, and on what kind of traffic is being
talking about, and on what kind of traffic is being sent." While the sent." While the first laptop, being physically close to the access
first laptop, being physically close to the access point, may have a point, may have a datarate of 54Mbps for unicast traffic, the other
datarate of 54Mbps for unicast traffic, the other laptop, being laptop, being relatively far away, or obstructed by some object, can
relatively far away, or obstructed by some object, can simultaneously simultaneously have a datarate of only 32Mbps for unicast. However,
have a datarate of only 32Mbps for unicast. However, for multicast for multicast traffic sent from the access point, all traffic is sent
traffic sent from the access point, all traffic is sent at the base at the base transmission rate (which is configurable, but depending
transmission rate (which is configurable, but depending on the model on the model of the access point, is usually 24Mbps or less).
of the access point, is usually 24Mbps or less).
In addition to utilizing variable datarate links, mobile networks are In addition to utilizing variable datarate links, mobile networks are
challenged by the notion that link connectivity will come and go over challenged by the notion that link connectivity will come and go over
time, without an effect on a router's interface state (Up or Down). time, without an effect on a router's interface state (Up or Down).
Effectively utilizing a relatively short-lived connection is Effectively utilizing a relatively short-lived connection is
problematic in IP routed networks, as routing protocols tend to rely problematic in IP routed networks, as routing protocols tend to rely
on interface state and independent timers at OSI Layer 3 to maintain on interface state and independent timers at OSI Layer 3 to maintain
network convergence (e.g., HELLO messages and/or recognition of DEAD network convergence (e.g., HELLO messages and/or recognition of DEAD
routing adjacencies). These dynamic connections can be better routing adjacencies). These dynamic connections can be better
utilized with an event-driven paradigm, where acquisition of a new utilized with an event-driven paradigm, where acquisition of a new
skipping to change at page 5, line 32 skipping to change at page 5, line 31
(current) best route through the network to a given destination is (current) best route through the network to a given destination is
difficult to establish and properly maintain. This is especially difficult to establish and properly maintain. This is especially
true of demand-based access schemes such as Demand Assigned Multiple true of demand-based access schemes such as Demand Assigned Multiple
Access (DAMA) implementations used on some satellite systems. With a Access (DAMA) implementations used on some satellite systems. With a
DAMA-based system, additional datarate may be available, but will not DAMA-based system, additional datarate may be available, but will not
be used unless the network devices emit traffic at a rate higher than be used unless the network devices emit traffic at a rate higher than
the currently established rate. Increasing the traffic rate does not the currently established rate. Increasing the traffic rate does not
guarantee additional datarate will be allocated; rather, it may guarantee additional datarate will be allocated; rather, it may
result in data loss and additional retransmissions on the link. result in data loss and additional retransmissions on the link.
Addressing the challenges listed above, the authors have developed Addressing the challenges listed above, the co-authors have developed
the Dynamic Link Exchange Protocol, or DLEP. The DLEP protocol runs the Dynamic Link Exchange Protocol, or DLEP. The DLEP protocol runs
between a router and its attached modem devices, allowing the modem between a router and its attached modem devices, allowing the modem
to communicate link characteristics as they change, and convergence to communicate link characteristics as they change, and convergence
events (acquisition and loss of potential routing destinations). The events (acquisition and loss of potential routing destinations). The
following diagrams are used to illustrate the scope of DLEP packets. following diagrams are used to illustrate the scope of DLEP packets.
|-------Local Node-------| |-------Remote Node------| |-------Local Node-------| |-------Remote Node------|
| | | | | | | |
+--------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +--------+
| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
skipping to change at page 6, line 7 skipping to change at page 6, line 7
+--------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +--------+
| | | Link | | | | | | Link | | |
|-DLEP--| | Protocol | |-DLEP--| |-DLEP--| | Protocol | |-DLEP--|
| | | (e.g. | | | | | | (e.g. | | |
| | | 802.11) | | | | | | 802.11) | | |
Figure 1: DLEP Network Figure 1: DLEP Network
In Figure 1, when the local modem detects the presence of a remote In Figure 1, when the local modem detects the presence of a remote
node, it (the local modem) sends a signal to its router via the DLEP node, it (the local modem) sends a signal to its router via the DLEP
protocol. Upon receipt of the signal, the local router may take protocol. The signal consists of an indication of what change has
whatever action it deems appropriate, such as initiating discovery occurred on the link (e.g., presence of a remote node detected),
protocols, and/or issuing HELLO messages to converge the network. On along with a collection of DLEP-defined Data Items that further
a continuing, as-needed basis, the modem devices utilize DLEP to describe the change. Upon receipt of the signal, the local router
report any characteristics of the link (datarate, latency, etc.) that may take whatever action it deems appropriate, such as initiating
have changed. DLEP is independent of the link type and topology discovery protocols, and/or issuing HELLO messages to converge the
supported by the modem. Note that the DLEP protocol is specified to network. On a continuing, as-needed basis, the modem devices use
run only on the local link between router and modem. Some over the DLEP to report any characteristics of the link (datarate, latency,
air signaling may be necessary between the local and remote modem in etc.) that have changed. DLEP is independent of the link type and
order to provide some parameters in DLEP signals between the local topology supported by the modem. Note that the DLEP protocol is
modem and local router, but DLEP does not specify how such over the specified to run only on the local link between router and modem.
air signaling is carried out. Over the air signaling is purely a Some over the air signaling may be necessary between the local and
matter for the modem implementer. remote modem in order to provide some parameters in DLEP signals
between the local modem and local router, but DLEP does not specify
how such over the air signaling is carried out. Over the air
signaling is purely a matter for the modem implementer.
Figure 2 shows how DLEP can support a configuration where routers are Figure 2 shows how DLEP can support a configuration where routers are
connected with different link types. In this example, Modem A connected with different link types. In this example, Modem A
implements a point-to-point link, and Modem B is connected via a implements a point-to-point link, and Modem B is connected via a
shared medium. In both cases, the DLEP protocol is used to report shared medium. In both cases, the DLEP protocol is used to report
the characteristics of the link (datarate, latency, etc.) to routers. the characteristics of the link (datarate, latency, etc.) to routers.
The modem is also able to use the DLEP session to notify the router The modem is also able to use the DLEP session to notify the router
when the remote node is lost, shortening the time required to re- when the remote node is lost, shortening the time required to re-
converge the network. converge the network.
skipping to change at page 7, line 37 skipping to change at page 7, line 37
| |
+---+----+ +---+----+
| Router | | Router |
| | | |
+--------+ +--------+
Figure 2: DLEP Network with Multiple Modem Devices Figure 2: DLEP Network with Multiple Modem Devices
1.1. Protocol Overview 1.1. Protocol Overview
DLEP defines a set of signals used by modems and their attached As mentioned earlier, DLEP defines a set of signals used by modems
routers. The signals are used to communicate events that occur on and their attached routers. The signals are used to communicate
the physical link(s) managed by the modem: for example, a remote node events that occur on the physical link(s) managed by the modem: for
entering or leaving the network, or that the link has changed. example, a remote node entering or leaving the network, or that the
Associated with these signals are a set of data items - information link has changed. Associated with these signals are a set of data
that describes the remote node (e.g., address information), and/or items - information that describes the remote node (e.g., address
the characteristics of the link to the remote node. information), and/or the characteristics of the link to the remote
node.
The protocol is defined as a collection of type-length-value (TLV) The protocol is defined as a collection of type-length-value (TLV)
based formats, specifying the signals that are exchanged between a based formats, specifying the signals that are exchanged between a
router and a modem, and the data items associated with the signal. router and a modem, and the data items associated with the signal.
This document specifies transport of DLEP signals and data items via This document specifies transport of DLEP signals and data items via
the TCP transport, with a UDP-based discovery mechanism. Other the TCP transport, with a UDP-based discovery mechanism. Other
transports for the protocol are possible, but are outside the scope transports for the protocol are possible, but are outside the scope
of this document. of this document.
DLEP uses a session-oriented paradigm between the modem device and DLEP uses a session-oriented paradigm between the modem device and
skipping to change at page 8, line 43 skipping to change at page 8, line 43
1.2. Requirements 1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. Assumptions 2. Assumptions
Routers and modems that exist as part of the same node (e.g., that Routers and modems that exist as part of the same node (e.g., that
are locally connected) can utilize a discovery technique to locate are locally connected) can use a discovery technique to locate each
each other, thus avoiding a-priori configuration. The router is other, thus avoiding a priori configuration. The router is
responsible for initializing the discovery process, using the Peer responsible for initializing the discovery process, using the Peer
Discovery signal (Section 7.1). Discovery signal (Section 7.1).
DLEP utilizes a session-oriented paradigm. A router and modem form a DLEP uses a session-oriented paradigm. A router and modem form a
session by completing the discovery and initialization process. This session by completing the discovery and initialization process. This
router-modem session persists unless or until it either (1) times router-modem session persists unless or until it either (1) times
out, based on the timeout values supplied, or (2) is explicitly torn out, based on the timeout values supplied, or (2) is explicitly torn
down by one of the participants. Note that while use of timers in down by one of the participants. Note that while use of timers in
DLEP is optional, it is strongly recommended that implementations DLEP is optional, it is strongly recommended that implementations
choose to run with timers enabled. choose to run with timers enabled.
DLEP assumes that the MAC address for delivering data traffic is the DLEP assumes that the MAC address for delivering data traffic is the
MAC specified in the Destination Up signal (Section 7.9). No MAC specified in the Destination Up signal (Section 7.9). No
manipulation or substitution is performed; the MAC address supplied manipulation or substitution is performed; the MAC address supplied
in Destination Up is used as the OSI Layer 2 Destination MAC address. in Destination Up is used as the OSI Layer 2 Destination MAC address.
DLEP also assumes that MAC addresses MUST be unique within the DLEP also assumes that MAC addresses MUST be unique within the
context of a router-modem session. Additionally, DLEP can support context of a router-modem session. Additionally, DLEP can support
MAC addresses in either EUI-48 or EUI-64 format, with the restriction MAC addresses in either EUI-48 or EUI-64 format, with the restriction
that ALL MAC addresses for a given DLEP session MUST be in the same that ALL MAC addresses for a given DLEP session MUST be in the same
format, and MUST be consistent with the MAC address format of the format, and MUST be consistent with the MAC address format of the
connected modem (e.g., if the modem is connected to the router with connected modem (e.g., if the modem is connected to the router with
an EUI-48 MAC, all destination addresses via that modem MUST be an EUI-48 MAC, all destination addresses via that modem MUST be
expressed in EUI-48 format). expressed in EUI-48 format).
DLEP utilizes UDP multicast for single-hop discovery, and TCP for DLEP uses UDP multicast for single-hop discovery, and TCP for
transport of the control signals. Therefore, DLEP assumes that the transport of the control signals. Therefore, DLEP assumes that the
modem and router have topologically consistent IP addresses assigned. modem and router have topologically consistent IP addresses assigned.
It is recommended that DLEP implementations utilize IPv6 link-local It is recommended that DLEP implementations utilize IPv6 link-local
addresses to reduce the administrative burden of address assignment. addresses to reduce the administrative burden of address assignment.
Destinations can be identified by either the router or the modem, and Destinations can be identified by either the router or the modem, and
represent a specific destination (e.g., an address) that exists on represent a specific destination (e.g., an address) that exists on
the link(s) managed by the modem. A destination MUST contain a MAC the link(s) managed by the modem. A destination MUST contain a MAC
address, it MAY optionally include a Layer 3 address (or addresses). address, it MAY optionally include a Layer 3 address (or addresses).
Note that since a destination is a MAC address, the MAC could Note that since a destination is a MAC address, the MAC could
skipping to change at page 10, line 23 skipping to change at page 10, line 23
DLEP has a core set of signals and data items that MUST be processed DLEP has a core set of signals and data items that MUST be processed
without error by an implementation in order to guarantee without error by an implementation in order to guarantee
interoperability and therefore make the implementation DLEP interoperability and therefore make the implementation DLEP
compliant. This document defines the core set of signals and data compliant. This document defines the core set of signals and data
items, listing them as 'mandatory'. It should be noted that some items, listing them as 'mandatory'. It should be noted that some
core signals and data items might not be used during the lifetime of core signals and data items might not be used during the lifetime of
a single DLEP session, but a compliant implementation MUST support a single DLEP session, but a compliant implementation MUST support
them. them.
While this document represents the best efforts of the co-authors, While this document represents the best efforts of the working group
and the working group, to be functionally complete, it is recognized to be functionally complete, it is recognized that extensions to DLEP
that extensions to DLEP will in all likelihood be necessary as more will in all likelihood be necessary as more link types are used. To
link types are utilized. To support future extension of DLEP, this support future extension of DLEP, this document describes an
document describes an extension negotiation capability to be used extension negotiation capability to be used during session
during session initialization via the Extensions Supported data item, initialization via the Extensions Supported data item, documented in
documented in Section 8.7 of this document. Section 8.7 of this document.
All extensions are considered OPTIONAL. Only the DLEP functionality All extensions are considered OPTIONAL. Only the DLEP functionality
listed as 'mandatory' is required by implementation in order to be listed as 'mandatory' is required by implementation in order to be
DLEP compliant. DLEP compliant.
This specification defines one extension, Credit windowing, exposed This specification defines one extension, Credit windowing, exposed
via the Extensions Supported mechanism that implementations MAY via the Extensions Supported mechanism that implementations MAY
choose to implement, or to omit. choose to implement, or to omit.
3.1. Negotiation of Optional Extensions 3.1. Negotiation of Optional Extensions
skipping to change at page 11, line 26 skipping to change at page 11, line 26
This document requests numbering space in both the DLEP signal and This document requests numbering space in both the DLEP signal and
data item registries for experimental items. The intent is to allow data item registries for experimental items. The intent is to allow
for experimentation with either (1) new signals, (2) new data items, for experimentation with either (1) new signals, (2) new data items,
or (3) both new signals and new data items, while still retaining the or (3) both new signals and new data items, while still retaining the
documented DLEP behavior. If a given experiment proves successful, documented DLEP behavior. If a given experiment proves successful,
it SHOULD be documented as an update to this document, or as a stand- it SHOULD be documented as an update to this document, or as a stand-
alone specification. alone specification.
Use of the experimental signals, data items, or behaviors MUST be Use of the experimental signals, data items, or behaviors MUST be
announced by inclusion of an Experimental Definition data item announced by inclusion of an Experimental Definition data item
(Section 8.8) with a value agreed upon (a-priori) between the (Section 8.8) with a value agreed upon (a priori) between the
participating peers. The exact mechanism for a-priori communication participating peers. The exact mechanism for a priori communication
of the experimental definition formats is beyond the scope of this of the experimental definition formats is beyond the scope of this
document. document.
Multiple Experimental Definition data items MAY appear in the Peer Multiple Experimental Definition data items MAY appear in the Peer
Initialization/Peer Initialization ACK sequence. However, use of Initialization/Peer Initialization ACK sequence. However, use of
multiple experiments in a single peer session could lead to multiple experiments in a single peer session could lead to
interoperability issues or unexpected results (e.g., redefinition of interoperability issues or unexpected results (e.g., redefinition of
experimental signals and/or data items), and is therefore experimental signals and/or data items), and is therefore
discouraged. It is left to implementations to determine the correct discouraged. It is left to implementations to determine the correct
processing path (e.g., a decision on whether to terminate the peer processing path (e.g., a decision on whether to terminate the peer
skipping to change at page 12, line 49 skipping to change at page 12, line 49
o Current Data Rate (Receive) (Section 8.16) o Current Data Rate (Receive) (Section 8.16)
o Current Data Rate (Transmit) (Section 8.17) o Current Data Rate (Transmit) (Section 8.17)
o Latency (Section 8.18) o Latency (Section 8.18)
5. DLEP Session Flow 5. DLEP Session Flow
For routers supporting DLEP, support of Discovery is optional. For routers supporting DLEP, support of Discovery is optional.
Therefore, normal session flow is described for both the 'Discovery Discovery is initiated in the DLEP modem by sending the Peer
case', and the 'Configured case'. For modem implementations of DLEP, Discovery Signal (Section 7.1) to a well-known multicast address.
support of Discovery is mandatory; therefore, that is the only case However, support for receipt and processing of the signal is optional
to be described. in the router (see Appendix A and B for flow diagrams of the
discovery signal). Due to the optional (on the router) support for
discovery, normal session flow is described for both the 'Discovery
case', and the 'Configured case'. Again, for modem implementations
of DLEP, support of Discovery is mandatory; therefore, that is the
only case to be described.
5.1. DLEP Router session flow - Discovery case 5.1. DLEP Router session flow - Discovery case
If the DLEP router implementation is utilizing the optional discovery If the DLEP router implementation is utilizing the optional discovery
mechanism, then the implementation will initialize a UDP socket, mechanism, then the implementation will initialize a UDP socket,
binding it to an arbitrary port. This UDP socket is used to send the binding it to an arbitrary port. This UDP socket is used to send the
Peer Discovery signal (Section 7.1) to the DLEP link-local multicast Peer Discovery signal (Section 7.1) to the DLEP link-local multicast
address and port (TBD). The implementation then waits on receipt of address and port (TBD). The implementation then waits on receipt of
a Peer Offer signal (Section 7.2), which MAY contain the unicast a Peer Offer signal (Section 7.2), which MAY contain the unicast
address and port for TCP-based communication with a DLEP modem, via address and port for TCP-based communication with a DLEP modem, via
skipping to change at page 15, line 6 skipping to change at page 15, line 14
5.4. Common Session Flow 5.4. Common Session Flow
In order to maintain the session between router and modem, periodic In order to maintain the session between router and modem, periodic
Heartbeat signals (Section 7.14) MAY be exchanged. These signals are Heartbeat signals (Section 7.14) MAY be exchanged. These signals are
intended to keep the session alive, and to verify bidirectional intended to keep the session alive, and to verify bidirectional
connectivity between the two participants. If heartbeat signals are connectivity between the two participants. If heartbeat signals are
exchanged, they do not begin until the DLEP peer session has entered exchanged, they do not begin until the DLEP peer session has entered
the 'in session' state. Each DLEP peer is responsible for the the 'in session' state. Each DLEP peer is responsible for the
creation of heartbeat signals. Receipt of any DLEP signal SHOULD creation of heartbeat signals. Receipt of any DLEP signal SHOULD
reset the heartbeat interval timer (e.g., valid DLEP signals take the reset the heartbeat interval timer (i.e., valid DLEP signals take the
place of, and obviate the need for, Heartbeat signals). place of, and obviate the need for, Heartbeat signals).
DLEP also provides a Peer Update signal (Section 7.5), intended to DLEP also provides a Peer Update signal (Section 7.5), intended to
communicate some change in status (e.g., a change of layer 3 address communicate some change in status (e.g., a change of layer 3 address
parameters, or a modem-wide link change). parameters, or a modem-wide link change).
In addition to the local (Peer level) signals above, the participants In addition to the local (Peer level) signals above, the participants
will transmit DLEP signals concerning destinations in the network. will transmit DLEP signals concerning destinations in the network.
These signals trigger creation/maintenance/deletion of destinations These signals trigger creation/maintenance/deletion of destinations
in the information base of the recipient. For example, a modem will in the information base of the recipient. For example, a modem will
skipping to change at page 16, line 5 skipping to change at page 16, line 9
received metrics is left to implementations. received metrics is left to implementations.
In addition to receiving metrics about the link, DLEP provides a In addition to receiving metrics about the link, DLEP provides a
signal allowing a router to request a different datarate, or latency, signal allowing a router to request a different datarate, or latency,
from the modem. This signal is referred to as the Link from the modem. This signal is referred to as the Link
Characteristics Request signal (Section 7.15), and gives the router Characteristics Request signal (Section 7.15), and gives the router
the ability to deal with requisite increases (or decreases) of the ability to deal with requisite increases (or decreases) of
allocated datarate/latency in demand-based schemes in a more allocated datarate/latency in demand-based schemes in a more
deterministic manner. deterministic manner.
6. DLEP Message Processing 6. DLEP Signal Processing
Communication between DLEP peers consists of a bidirectional stream Communication between DLEP peers consists of a bidirectional stream
of signals, each signal consisting of a signal header and an of signals (messages), each signal consisting of a signal header and
unordered list of data items. Both signal headers and data items are an unordered list of data items. Signal headers consist of Type and
encoded as TLV (Type-Length-Value) structures. In this document, the Length information, while data items are encoded as TLV (Type-Length-
data items following the signal header are described as being Value) structures. In this document, the data items following the
'contained in' the signal. signal header are described as being 'contained in' the signal.
All integer values in all TLV structures MUST be in network byte- All integer values structures MUST be in network byte-order.
order.
There is no restriction on the order of data items following a There is no restriction on the order of data items following a
signal, and the multiplicity of duplicate data items is defined by signal, and the multiplicity of duplicate data items is defined by
the definition of the signal declared by the type in the signal the definition of the signal declared by the type in the signal
header. header.
If an unrecognized, or unexpected signal is received, or a received If an unrecognized, or unexpected signal is received, or a received
signal contains unrecognized, invalid or disallowed duplicate data signal contains unrecognized, invalid, or disallowed duplicate data
items, the receiving peer MUST terminate the session by issuing a items, the receiving peer MUST terminate the session by issuing a
Peer Termination signal (Section 7.7) with a Status data item Peer Termination signal (Section 7.7) with a Status data item
(Section 8.2) containing the most relevant status code, and then (Section 8.2) containing the most relevant status code, and then
close the TCP connection. close the TCP connection.
6.1. DLEP Signal Header 6.1. DLEP Signal Header
The DLEP signal header contains the following fields: The DLEP signal header contains the following fields:
0 1 2 0 1 2
skipping to change at page 18, line 5 skipping to change at page 18, line 5
specific signals, this header structure is assumed, and will not be specific signals, this header structure is assumed, and will not be
replicated. replicated.
Following is the set of MANDATORY signals that must be recognized by Following is the set of MANDATORY signals that must be recognized by
a DLEP compliant implementation. As mentioned before, not all a DLEP compliant implementation. As mentioned before, not all
signals may be used during a session, but an implementation MUST signals may be used during a session, but an implementation MUST
correctly process these signals when received. correctly process these signals when received.
The mandatory DLEP signals are: The mandatory DLEP signals are:
+---------+-------------------------------+---------------+ +--------+--------------------+----------------------+--------------+
| Signal | Description | Section | | Signal | Description | Mnemonic | Section |
+---------+-------------------------------+---------------+ +--------+--------------------+----------------------+--------------+
| TBD | Peer Discovery | Section 7.1 | | TBD | Peer Discovery | DLEP_PEER_DISCOVERY | Section 7.1 |
| TBD | Peer Offer | Section 7.2 | | TBD | Peer Offer | DLEP_PEER_OFFER | Section 7.2 |
| TBD | Peer Initialization | Section 7.3 | | TBD | Peer | DLEP_PEER_INIT | Section 7.3 |
| TBD | Peer Initialization ACK | Section 7.4 | | | Initialization | | |
| TBD | Peer Update | Section 7.5 | | TBD | Peer | DLEP_PEER_INIT_ACK | Section 7.4 |
| TBD | Peer Update ACK | Section 7.6 | | | Initialization ACK | | |
| TBD | Peer Termination | Section 7.7 | | TBD | Peer Update | DLEP_PEER_UPDATE | Section 7.5 |
| TBD | Peer Termination ACK | Section 7.8 | | TBD | Peer Update ACK | DLEP_PEER_UPDATE_ACK | Section 7.6 |
| TBD | Destination Up | Section 7.9 | | TBD | Peer Termination | DLEP_PEER_TERM | Section 7.7 |
| TBD | Destination Up ACK | Section 7.10 | | TBD | Peer Termination | DLEP_PEER_TERM_ACK | Section 7.8 |
| TBD | Destination Down | Section 7.11 | | | ACK | | |
| TBD | Destination Down ACK | Section 7.12 | | TBD | Destination Up | DLEP_DEST_UP | Section 7.9 |
| TBD | Destination Update | Section 7.13 | | TBD | Destination Up ACK | DLEP_DEST_UP_ACK | Section 7.10 |
| TBD | Heartbeat | Section 7.14 | | TBD | Destination Down | DLEP_DEST_DOWN | Section 7.11 |
| TBD | Link Characteristics Request | Section 7.15 | | TBD | Destination Down | DLEP_DEST_DOWN_ACK | Section 7.12 |
| TBD | Link Characteristics ACK | Section 7.16 | | | ACK | | |
+---------+-------------------------------+---------------+ | TBD | Destination Update | DLEP_DEST_UPDATE | Section 7.13 |
| TBD | Heartbeat | DLEP_PEER_HEARTBEAT | Section 7.14 |
| TBD | Link | DLEP_LINK_CHAR_REQ | Section 7.15 |
| | Characteristics | | |
| | Request | | |
| TBD | Link | DLEP_LINK_CHAR_ACK | Section 7.16 |
| | Characteristics | | |
| | ACK | | |
+--------+--------------------+----------------------+--------------+
Table 1: DLEP Signal Values
7.1. Peer Discovery Signal 7.1. Peer Discovery Signal
A Peer Discovery signal SHOULD be sent by a router to discover DLEP A Peer Discovery signal SHOULD be sent by a router to discover DLEP
modems in the network. The Peer Offer signal (Section 7.2) is modems in the network. The Peer Offer signal (Section 7.2) is
required to complete the discovery process. Implementations MAY required to complete the discovery process. Implementations MAY
implement their own retry heuristics in cases where it is determined implement their own retry heuristics in cases where it is determined
the Peer Discovery signal has timed out. the Peer Discovery signal has timed out.
To construct a Peer Discovery signal, the Signal Type value in the To construct a Peer Discovery signal, the Signal Type value in the
signal header is set to DLEP_PEER_DISCOVERY (value TBD). signal header is set to DLEP_PEER_DISCOVERY in Table 1.
The Peer Discovery signal MUST contain the following data item: The Peer Discovery signal MUST contain the following data item:
o DLEP Version (Section 8.1) o DLEP Version (Section 8.1)
The Peer Discovery signal MAY contain the following data item: The Peer Discovery signal MAY contain the following data item:
o Peer Type (Section 8.5) o Peer Type (Section 8.5)
7.2. Peer Offer Signal 7.2. Peer Offer Signal
A Peer Offer signal MUST be sent by a DLEP modem in response to a A Peer Offer signal MUST be sent by a DLEP modem in response to a
valid Peer Discovery signal (Section 7.1). valid Peer Discovery signal (Section 7.1).
The Peer Offer signal MUST be sent to the unicast address of the The Peer Offer signal MUST be sent to the unicast address of the
originator of the Peer Discovery signal. originator of the Peer Discovery signal.
To construct a Peer Offer signal, the Signal Type value in the signal To construct a Peer Offer signal, the Signal Type value in the signal
header is set to DLEP_PEER_OFFER (value TBD). header is set to DLEP_PEER_OFFER in Table 1.
The Peer Offer signal MUST contain the following data item: The Peer Offer signal MUST contain the following data item:
o DLEP Version (Section 8.1) o DLEP Version (Section 8.1)
The Peer Offer signal MAY contain the following data item: The Peer Offer signal MAY contain the following data item:
o Peer Type (Section 8.5) o Peer Type (Section 8.5)
The Peer Offer signal MAY contain one or more of any of the following The Peer Offer signal MAY contain one or more of any of the following
skipping to change at page 19, line 37 skipping to change at page 19, line 47
the address to connect to. If no IP Connection Point data items are the address to connect to. If no IP Connection Point data items are
included in the Peer Offer signal, the receiver MUST use the origin included in the Peer Offer signal, the receiver MUST use the origin
address of the signal as the IP address, and the DLEP well-known port address of the signal as the IP address, and the DLEP well-known port
number (Section 11.7) to establish the TCP connection. number (Section 11.7) to establish the TCP connection.
7.3. Peer Initialization Signal 7.3. Peer Initialization Signal
A Peer Initialization signal MUST be sent by a router as the first A Peer Initialization signal MUST be sent by a router as the first
signal of the DLEP TCP session. It is sent by the router after a TCP signal of the DLEP TCP session. It is sent by the router after a TCP
connect to an address/port combination that was obtained either via connect to an address/port combination that was obtained either via
receipt of a Peer Offer, or from a-priori configuration. receipt of a Peer Offer, or from a priori configuration.
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 Peer Extensions Supported data item does NOT exist in a Peer
Initialization signal, the receiver of the signal MUST conclude that Initialization signal, the receiver of the signal MUST conclude that
there is NO support for extensions in the sender. there is NO support for extensions in the sender.
If any experimental signals or data items are used by the If any experimental signals or data items are used by the
implementation, they MUST be enumerated in one or more Experimental implementation, they MUST be enumerated in one or more Experimental
Definition data items. If there are no Experimental Definition data Definition data items. If there are no Experimental Definition data
skipping to change at page 20, line 12 skipping to change at page 20, line 21
MUST conclude that NO experimental definitions are in use by the MUST conclude that NO experimental definitions are in use by the
sender. sender.
Implementations supporting the Heartbeat Interval (Section 8.6) Implementations supporting the Heartbeat Interval (Section 8.6)
should understand that heartbeats are NOT fully established until should understand that heartbeats are NOT fully established until
receipt of Peer Initialization ACK Signal (Section 7.4), and should receipt of Peer Initialization ACK Signal (Section 7.4), and should
therefore implement their own timeout and retry heurestics for this therefore implement their own timeout and retry heurestics for this
signal. signal.
To construct a Peer Initialization signal, the Signal Type value in To construct a Peer Initialization signal, the Signal Type value in
the signal header is set to DLEP_PEER_INITIALIZATION (value TBD). the signal header is set to DLEP_PEER_INIT in Table 1.
The Peer Initialization signal MUST contain one of each of the The Peer Initialization signal MUST contain one of each of the
following data items: following data items:
o DLEP Version (Section 8.1) o DLEP Version (Section 8.1)
o Heartbeat Interval (Section 8.6) o Heartbeat Interval (Section 8.6)
The Peer Initialization signal MAY contain one of each of the The Peer Initialization signal MAY contain one of each of the
following data items: following data items:
skipping to change at page 21, line 19 skipping to change at page 21, line 29
support for extensions in the sender. support for extensions in the sender.
If any experimental signals or data items are used by the If any experimental signals or data items are used by the
implementation, they MUST be enumerated in one or more Experimental implementation, they MUST be enumerated in one or more Experimental
Definition data items. If there are no Experimental Definition data Definition data items. If there are no Experimental Definition data
items in a Peer Initialization ACK signal, the receiver of the signal items in a Peer Initialization ACK signal, the receiver of the signal
MUST conclude that NO experimental definitions are in use by the MUST conclude that NO experimental definitions are in use by the
sender. sender.
After the Peer Initialization/Peer Initialization ACK signals have After the Peer Initialization/Peer Initialization ACK signals have
been successfully exchanged, implementations MUST only utilize been successfully exchanged, implementations MUST only use extensions
extensions and experimental definitions that are supported by BOTH and experimental definitions that are supported by BOTH peers.
peers.
To construct a Peer Initialization ACK signal, the Signal Type value To construct a Peer Initialization ACK signal, the Signal Type value
in the signal header is set to DLEP_PEER_INIT_ACK (value TBD). in the signal header is set to DLEP_PEER_INIT_ACK in Table 1.
The Peer Initialization ACK signal MUST contain one of each of the The Peer Initialization ACK signal MUST contain one of each of the
following data items: following data items:
o DLEP Version (Section 8.1) o DLEP Version (Section 8.1)
o Heartbeat Interval (Section 8.6) o Heartbeat Interval (Section 8.6)
o Maximum Data Rate (Receive) (Section 8.14) o Maximum Data Rate (Receive) (Section 8.14)
skipping to change at page 23, line 6 skipping to change at page 23, line 14
therefore MUST be applied to all destinations in the information base therefore MUST be applied to all destinations in the information base
associated with the router/modem session. associated with the router/modem session.
Supporting implementations are free to employ heuristics to Supporting implementations are free to employ heuristics to
retransmit Peer Update signals. The sending of Peer Update signals retransmit Peer Update signals. The sending of Peer Update signals
for Layer 3 address changes SHOULD cease when either participant for Layer 3 address changes SHOULD cease when either participant
(router or modem) determines that the other implementation does NOT (router or modem) determines that the other implementation does NOT
support Layer 3 address tracking. support Layer 3 address tracking.
To construct a Peer Update signal, the Signal Type value in the To construct a Peer Update signal, the Signal Type value in the
signal header is set to DLEP_PEER_UPDATE (value TBD). signal header is set to DLEP_PEER_UPDATE in Table 1.
The Peer Update signal MAY contain one of each of the following data The Peer Update signal MAY contain one of each of the following data
items: items:
o Maximum Data Rate (Receive) (Section 8.14) o Maximum Data Rate (Receive) (Section 8.14)
o Maximum Data Rate (Transmit) (Section 8.15) o Maximum Data Rate (Transmit) (Section 8.15)
o Current Data Rate (Receive) (Section 8.16) o Current Data Rate (Receive) (Section 8.16)
skipping to change at page 23, line 45 skipping to change at page 24, line 6
A Peer Update signal MUST be acknowledged by the receiver issuing a A Peer Update signal MUST be acknowledged by the receiver issuing a
Peer Update ACK signal (Section 7.6). Peer Update ACK signal (Section 7.6).
7.6. Peer Update ACK Signal 7.6. Peer Update ACK Signal
A Peer Update ACK signal MUST be sent by implementations to indicate A Peer Update ACK signal MUST be sent by implementations to indicate
whether a Peer Update signal (Section 7.5) was successfully received. whether a Peer Update signal (Section 7.5) was successfully received.
To construct a Peer Update ACK signal, the Signal Type value in the To construct a Peer Update ACK signal, the Signal Type value in the
signal header is set to DLEP_PEER_UPDATE_ACK (value TBD). signal header is set to DLEP_PEER_UPDATE_ACK in Table 1.
The Peer Update ACK signal MAY contain one of each of the following The Peer Update ACK signal MAY contain one of each of the following
data items: data items:
o Status (Section 8.2) o Status (Section 8.2)
A receiver of a Peer Update ACK signal without a Status data item A receiver of a Peer Update ACK signal without a Status data item
MUST behave as if a Status data item with code 'Success' had been MUST behave as if a Status data item with code 'Success' had been
received. received.
7.7. Peer Termination Signal 7.7. Peer Termination Signal
A Peer Termination signal MUST be sent by a DLEP participant when the A Peer Termination signal MUST be sent by a DLEP participant when the
router/modem session needs to be terminated. Implementations router/modem session needs to be terminated. Implementations
receiving a Peer Termination signal MUST send a Peer Termination ACK receiving a Peer Termination signal MUST send a Peer Termination ACK
signal (Section 7.8) to confirm the termination process. signal (Section 7.8) to confirm the termination process.
skipping to change at page 24, line 27 skipping to change at page 24, line 36
destinations in the information base accessible via the router/modem destinations in the information base accessible via the router/modem
pair represented by the session. Router and modem state machines are pair represented by the session. Router and modem state machines are
returned to the 'discovery' state. No Destination Down signals returned to the 'discovery' state. No Destination Down signals
(Section 7.11) are sent. (Section 7.11) are sent.
The sender of a Peer Termination signal is free to define its The sender of a Peer Termination signal is free to define its
heuristics in event of a timeout. It may resend the Peer Termination heuristics in event of a timeout. It may resend the Peer Termination
or free resources and return to the 'discovery' state. or free resources and return to the 'discovery' state.
To construct a Peer Termination signal, the Signal Type value in the To construct a Peer Termination signal, the Signal Type value in the
signal header is set to DLEP_PEER_TERMINATION (value TBD). signal header is set to DLEP_PEER_TERM in Table 1.
The Peer Termination signal MAY contain one of each of the following The Peer Termination signal MAY contain one of each of the following
data items: data items:
o Status (Section 8.2) o Status (Section 8.2)
A receiver of a Peer Termination signal without a Status data item A receiver of a Peer Termination signal without a Status data item
MUST behave as if a Status data item with status code 'Success', MUST behave as if a Status data item with status code 'Success',
implying graceful termination, had been received. implying graceful termination, had been received.
skipping to change at page 24, line 49 skipping to change at page 25, line 13
issuing a Peer Termination ACK signal (Section 7.8). issuing a Peer Termination ACK signal (Section 7.8).
7.8. Peer Termination ACK Signal 7.8. Peer Termination ACK Signal
A Peer Termination ACK signal MUST be sent by a DLEP peer in response A Peer Termination ACK signal MUST be sent by a DLEP peer in response
to a received Peer Termination signal (Section 7.7). Receipt of a to a received Peer Termination signal (Section 7.7). Receipt of a
Peer Termination ACK signal completes the teardown of the router/ Peer Termination ACK signal completes the teardown of the router/
modem session. modem session.
To construct a Peer Termination ACK signal, the Signal Type value in To construct a Peer Termination ACK signal, the Signal Type value in
the signal header is set to DLEP_PEER_TERMINATION_ACK (value TBD). the signal header is set to DLEP_PEER_TERM_ACK in Table 1.
The Peer Termination ACK signal MAY contain one of each of the The Peer Termination ACK signal MAY contain one of each of the
following data items: following data items:
o Status (Section 8.2) o Status (Section 8.2)
A receiver of a Peer Termination ACK signal without a Status data A receiver of a Peer Termination ACK signal without a Status data
item MUST behave as if a Status data item with status code 'Success', item MUST behave as if a Status data item with status code 'Success',
implying graceful termination, had been received. implying graceful termination, had been received.
skipping to change at page 25, line 30 skipping to change at page 25, line 40
A Destination Up signal MUST be acknowledged by the receiver issuing A Destination Up signal MUST be acknowledged by the receiver issuing
a Destination Up ACK signal (Section 7.10). The sender of the a Destination Up ACK signal (Section 7.10). The sender of the
Destination Up signal is free to define its retry heuristics in event Destination Up signal is free to define its retry heuristics in event
of a timeout. When a Destination Up signal is received and of a timeout. When a Destination Up signal is received and
successfully processed, the receiver should add knowledge of the new successfully processed, the receiver should add knowledge of the new
destination to its information base, indicating that the destination destination to its information base, indicating that the destination
is accessible via the modem/router pair. is accessible via the modem/router pair.
To construct a Destination Up signal, the Signal Type value in the To construct a Destination Up signal, the Signal Type value in the
signal header is set to DLEP_DESTINATION_UP (value TBD). signal header is set to DLEP_DEST_UP in Table 1.
The Destination Up signal MUST contain one of each of the following The Destination Up signal MUST contain one of each of the following
data items: data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
The Destination Up signal MAY contain one of each of the following The Destination Up signal MAY contain one of each of the following
data items: data items:
o Maximum Data Rate (Receive) (Section 8.14) o Maximum Data Rate (Receive) (Section 8.14)
skipping to change at page 26, line 31 skipping to change at page 26, line 41
Destination Up signal, reducing the need for the receiver to probe Destination Up signal, reducing the need for the receiver to probe
for any address. for any address.
7.10. Destination Up ACK Signal 7.10. Destination Up ACK Signal
A DLEP participant MUST send a Destination Up ACK signal to indicate A DLEP participant MUST send a Destination Up ACK signal to indicate
whether a Destination Up signal (Section 7.9) was successfully whether a Destination Up signal (Section 7.9) was successfully
processed. processed.
To construct a Destination Up ACK signal, the Signal Type value in To construct a Destination Up ACK signal, the Signal Type value in
the signal header is set to DLEP_DESTINATION_UP_ACK (value TBD). the signal header is set to DLEP_DEST_UP_ACK in Table 1.
The Destination Up ACK signal MUST contain one of each of the The Destination Up ACK signal MUST contain one of each of the
following data items: following data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
The Destination Up ACK signal MAY contain one of each of the The Destination Up ACK signal MAY contain one of each of the
following data items: following data items:
o Status (Section 8.2) o Status (Section 8.2)
skipping to change at page 27, line 16 skipping to change at page 27, line 20
A DLEP peer MUST send a Destination Down signal to report when a A DLEP peer MUST send a Destination Down signal to report when a
destination (a remote node or a multicast group) is no longer destination (a remote node or a multicast group) is no longer
reachable. A Destination Down ACK signal (Section 7.12) MUST be sent reachable. A Destination Down ACK signal (Section 7.12) MUST be sent
by the recipient of a Destination Down signal to confirm that the by the recipient of a Destination Down signal to confirm that the
relevant data has been removed from the information base. The sender relevant data has been removed from the information base. The sender
of the Destination Down signal is free to define its retry heuristics of the Destination Down signal is free to define its retry heuristics
in event of a timeout. in event of a timeout.
To construct a Destination Down signal, the Signal Type value in the To construct a Destination Down signal, the Signal Type value in the
signal header is set to DLEP_DESTINATION_DOWN (value TBD). signal header is set to DLEP_DEST_DOWN in Table 1.
The Destination Down signal MUST contain one of each of the following The Destination Down signal MUST contain one of each of the following
data items: data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
7.12. Destination Down ACK Signal 7.12. Destination Down ACK Signal
A DLEP participant MUST send a Destination Down ACK signal to A DLEP participant MUST send a Destination Down ACK signal to
indicate whether a received Destination Down signal (Section 7.11) indicate whether a received Destination Down signal (Section 7.11)
was successfully processed. If successfully processed, the sender of was successfully processed. If successfully processed, the sender of
the ACK MUST have removed all entries in the information base that the ACK MUST have removed all entries in the information base that
pertain to the referenced destination. pertain to the referenced destination.
To construct a Destination Down ACK signal, the Signal Type value in To construct a Destination Down ACK signal, the Signal Type value in
the signal header is set to DLEP_DESTINATION_DOWN_ACK (value TBD). the signal header is set to DLEP_DEST_DOWN_ACK in Table 1.
The Destination Down ACK signal MUST contain one of each of the The Destination Down ACK signal MUST contain one of each of the
following data items: following data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
The Destination Down ACK signal MAY contain one of each of the The Destination Down ACK signal MAY contain one of each of the
following data items: following data items:
o Status (Section 8.2) o Status (Section 8.2)
skipping to change at page 28, line 17 skipping to change at page 28, line 19
A DLEP participant SHOULD send the Destination Update signal when it A DLEP participant SHOULD send the Destination Update signal when it
detects some change in the information base for a given destination detects some change in the information base for a given destination
(remote node or multicast group). Some examples of changes that (remote node or multicast group). Some examples of changes that
would prompt a Destination Update signal are: would prompt a Destination Update signal are:
o Change in link metrics (e.g., Data Rates) o Change in link metrics (e.g., Data Rates)
o Layer 3 addressing change o Layer 3 addressing change
To construct a Destination Update signal, the Signal Type value in To construct a Destination Update signal, the Signal Type value in
the signal header is set to DLEP_DESTINATION_UPDATE (value TBD). the signal header is set to DLEP_DEST_UPDATE in Table 1.
The Destination Update signal MUST contain one of each of the The Destination Update signal MUST contain one of each of the
following data items: following data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
The Destination Update signal MAY contain one of each of the The Destination Update signal MAY contain one of each of the
following data items: following data items:
o Maximum Data Rate (Receive) (Section 8.14) o Maximum Data Rate (Receive) (Section 8.14)
skipping to change at page 29, line 22 skipping to change at page 29, line 26
Heartbeat Interval to 0 effectively set the interval to an infinite Heartbeat Interval to 0 effectively set the interval to an infinite
value, therefore, in those cases, this signal SHOULD NOT be sent. value, therefore, in those cases, this signal SHOULD NOT be sent.
The signal is used by participants to detect when a DLEP session The signal is used by participants to detect when a DLEP session
partner (either the modem or the router) is no longer communicating. partner (either the modem or the router) is no longer communicating.
Participants SHOULD allow two (2) heartbeat intervals to expire with Participants SHOULD allow two (2) heartbeat intervals to expire with
no traffic on the router/modem session before initiating DLEP session no traffic on the router/modem session before initiating DLEP session
termination procedures. termination procedures.
To construct a Heartbeat signal, the Signal Type value in the signal To construct a Heartbeat signal, the Signal Type value in the signal
header is set to DLEP_PEER_HEARTBEAT (value TBD). header is set to DLEP_PEER_HEARTBEAT in Table 1.
There are no valid data items for the Heartbeat signal. There are no valid data items for the Heartbeat signal.
7.15. Link Characteristics Request Signal 7.15. Link Characteristics Request Signal
The Link Characteristics Request signal MAY be sent by the router to The Link Characteristics Request signal MAY be sent by the router to
request that the modem initiate changes for specific characteristics request that the modem initiate changes for specific characteristics
of the link. The request can reference either a real destination of the link. The request can reference either a real destination
(e.g., a remote node), or a logical destination (e.g., a multicast (e.g., a remote node), or a logical destination (e.g., a multicast
group) within the network. group) within the network.
skipping to change at page 29, line 47 skipping to change at page 30, line 4
traffic delay on the link not exceed the specified value, or both. A traffic delay on the link not exceed the specified value, or both. A
Link Characteristics ACK signal (Section 7.16) is required to Link Characteristics ACK signal (Section 7.16) is required to
complete the request. Issuing a Link Characteristics Request with complete the request. Issuing a Link Characteristics Request with
ONLY the MAC Address data item is a mechanism a peer MAY use to ONLY the MAC Address data item is a mechanism a peer MAY use to
request metrics (via the Link Characteristics ACK) from its partner. request metrics (via the Link Characteristics ACK) from its partner.
The sender of a Link Characteristics Request signal MAY attach a The sender of a Link Characteristics Request signal MAY attach a
timer to the request using the Link Characteristics ACK Timer data timer to the request using the Link Characteristics ACK Timer data
item. If a Link Characteristics ACK signal is received after the item. If a Link Characteristics ACK signal is received after the
timer expires, the sender MUST NOT assume that the request succeeded. timer expires, the sender MUST NOT assume that the request succeeded.
Implementations are free to define their retry heuristics in event of Implementations are free to define their retry heuristics in event of
a timeout. a timeout.
To construct a Link Characteristics Request signal, the Signal Type To construct a Link Characteristics Request signal, the Signal Type
value in the signal header is set to DLEP_LINK_CHAR_REQ (value TBD). value in the signal header is set to DLEP_LINK_CHAR_REQ in Table 1.
The Link Characteristics Request signal MUST contain one of each of The Link Characteristics Request signal MUST contain one of each of
the following data items: the following data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
The Link Characteristics Request signal MAY contain one of each of The Link Characteristics Request signal MAY contain one of each of
the following data items: the following data items:
o Link Characteristics ACK Timer (Section 8.23) o Link Characteristics ACK Timer (Section 8.23)
skipping to change at page 30, line 39 skipping to change at page 30, line 45
by only including a MAC address data item. It MUST contain the same by only including a MAC address data item. It MUST contain the same
metric types as the request. The values in the metric data items in metric types as the request. The values in the metric data items in
the Link Characteristics ACK signal MUST reflect the link the Link Characteristics ACK signal MUST reflect the link
characteristics after the request has been processed. characteristics after the request has been processed.
If an implementation is not able to alter the characteristics of the If an implementation is not able to alter the characteristics of the
link in the manner requested, then a Status data item with status link in the manner requested, then a Status data item with status
code 'Request Denied' MUST be added to the signal. code 'Request Denied' MUST be added to the signal.
To construct a Link Characteristics Request ACK signal, the Signal To construct a Link Characteristics Request ACK signal, the Signal
Type value in the signal header is set to DLEP_LINK_CHAR_ACK (value Type value in the signal header is set to DLEP_LINK_CHAR_ACK in
TBD). Table 1.
The Link Characteristics ACK signal MUST contain one of each of the The Link Characteristics ACK signal MUST contain one of each of the
following data items: following data items:
o MAC Address (Section 8.9) o MAC Address (Section 8.9)
The Link Characteristics ACK signal SHOULD contain one of each of the The Link Characteristics ACK signal SHOULD contain one of each of the
following data items: following data items:
o Maximum Data Rate (Receive) (Section 8.14) o Maximum Data Rate (Receive) (Section 8.14)
o Maximum Data Rate (Transmit) (Section 8.15) o Maximum Data Rate (Transmit) (Section 8.15)
o Current Data Rate (Receive) (Section 8.16) o Current Data Rate (Receive) (Section 8.16)
o Current Data Rate (Transmit) (Section 8.17) o Current Data Rate (Transmit) (Section 8.17)
o Latency (Section 8.18) o Latency (Section 8.18)
The Link Characteristics ACK signal MAY contain one of each of the The Link Characteristics ACK signal MAY contain one of each of the
following data items: following data items:
o Resources (Receive) (Section 8.19) o Resources (Receive) (Section 8.19)
skipping to change at page 32, line 35 skipping to change at page 32, line 35
| TBD | Latency | Section 8.18 | | TBD | Latency | Section 8.18 |
| TBD | Resources (Receive) (RESR) | Section 8.19 | | TBD | Resources (Receive) (RESR) | Section 8.19 |
| TBD | Resources (Transmit) (REST) | Section 8.20 | | TBD | Resources (Transmit) (REST) | Section 8.20 |
| TBD | Relative Link Quality (Receive) | Section 8.21 | | TBD | Relative Link Quality (Receive) | Section 8.21 |
| | (RLQR) | | | | (RLQR) | |
| TBD | Relative Link Quality (Transmit) | Section 8.22 | | TBD | Relative Link Quality (Transmit) | Section 8.22 |
| | (RLQT) | | | | (RLQT) | |
| TBD | Link Characteristics ACK Timer | Section 8.23 | | TBD | Link Characteristics ACK Timer | Section 8.23 |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
Table 2: DLEP Data Item Values
8.1. DLEP Version 8.1. DLEP Version
The DLEP Version data item MUST appear in the Peer Discovery The DLEP Version data item MUST appear in the Peer Discovery
(Section 7.1), Peer Offer (Section 7.2), Peer Initialization (Section 7.1), Peer Offer (Section 7.2), Peer Initialization
(Section 7.3) and Peer Initialization ACK (Section 7.4) signals. The (Section 7.3) and Peer Initialization ACK (Section 7.4) signals. The
Version data item is used to indicate the version of the protocol Version data item is used to indicate the version of the protocol
running in the originator. A DLEP implementation SHOULD use this running in the originator. A DLEP implementation SHOULD use this
information to decide if the potential session partner is running at information to decide if the potential session partner is running at
a supported level. a supported level.
skipping to change at page 33, line 24 skipping to change at page 33, line 24
Length: 4 Length: 4
Major Version: The major version of the DLEP protocol, expressed as Major Version: The major version of the DLEP protocol, expressed as
an 16-bit unsigned integer. an 16-bit unsigned integer.
Minor Version: The minor version of the DLEP protocol, expressed as Minor Version: The minor version of the DLEP protocol, expressed as
an 16-bit unsigned integer. an 16-bit unsigned integer.
Support of this draft is indicated by setting the Major Version to Support of this draft is indicated by setting the Major Version to
'0', and the Minor Version to '9' (i.e. Version 0.9). '1', and the Minor Version to '0' (i.e. Version 1.0).
8.2. Status 8.2. Status
The Status data item MAY appear in the Peer Initialization ACK The Status data item MAY appear in the Peer Initialization ACK
(Section 7.4), Peer Termination (Section 7.7), Peer Termination ACK (Section 7.4), Peer Termination (Section 7.7), Peer Termination ACK
(Section 7.8), Peer Update ACK (Section 7.6), Destination Up ACK (Section 7.8), Peer Update ACK (Section 7.6), Destination Up ACK
(Section 7.10), Destination Down ACK (Section 7.12) and Link (Section 7.10), Destination Down ACK (Section 7.12) and Link
Characteristics ACK (Section 7.16) signals as part of an Characteristics ACK (Section 7.16) signals as part of an
acknowledgement from either the modem or the router, to indicate the acknowledgement from either the modem or the router, to indicate the
success or failure of the previously received signal. success or failure of the previously received signal.
skipping to change at page 34, line 7 skipping to change at page 34, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length | Code | Text... | Data Item Type| Length | Code | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 1 + Length of text Length: 1 + Length of text
Status Code: One of the codes defined below. Status Code: One of the codes defined below.
Text: UTF-8 encoded string, describing an problem, used for Text: UTF-8 encoded string, describing an problem, used for
implementation defined purposes. implementation defined purposes. Since this field is used for a
description of the problem, implementations SHOULD limit
characters in this field to printable characters. Implementations
receiving this data item SHOULD check for 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 Code | Value | Reason | | Status Code | Value | Reason |
+----------------+-------+------------------------------------------+ +----------------+-------+------------------------------------------+
| Success | 0 | The signal was processed successfully. | | Success | 0 | The signal was processed successfully. |
| Unknown Signal | TBD | The signal was not recognized by the | | Unknown Signal | TBD | The signal was not recognized by the |
| | | implementation. | | | | implementation. |
| Invalid Data | TBD | One or more data items in the signal are | | Invalid Data | TBD | One or more data items in the signal are |
skipping to change at page 36, line 31 skipping to change at page 36, line 36
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 | Peer Type | | Data Item Type| Length | Peer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: Length of peer type string. Length: Length of peer type string.
Peer Type: UTF-8 encoded string. For example, a satellite modem Peer Type: UTF-8 encoded string. For example, a satellite modem
might set this variable to "Satellite terminal". might set this variable to "Satellite terminal". Since this data
item is intended to provide additional information for display
commands, sending implementations SHOULD limit the data to
printable characters, and receiving implmentations 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.
8.6. Heartbeat Interval 8.6. Heartbeat Interval
The Heartbeat Interval data item MUST appear in both the Peer The Heartbeat Interval data item MUST appear in both the Peer
Initialization (Section 7.3) and Peer Initialization ACK Initialization (Section 7.3) and Peer Initialization ACK
(Section 7.4) signals to indicate the Heartbeat timeout window to be (Section 7.4) signals to indicate the Heartbeat timeout window to be
used by the sender. used by the sender.
skipping to change at page 38, line 20 skipping to change at page 38, line 30
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 | Experiment Name | | Data Item Type| Length | Experiment Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: Length of the name string for the Experiment. Length: Length of the name string for the Experiment.
Experiment Name: UTF-8 encoded string, containing the name of the Experiment Name: UTF-8 encoded string, containing the name of the
experiment being utilized. experiment being implemented.
An implementation receiving this data item MUST compare the received An implementation receiving this data item MUST compare the received
string to a list of experiments that it supports. string to a list of experiments that it supports.
An implementation MUST NOT assume the Experiment Name field is NUL- An implementation MUST NOT assume the Experiment Name field is NUL-
terminated. terminated.
8.9. MAC Address 8.9. MAC Address
The MAC address data item MUST appear in all destination-oriented The MAC address data item MUST appear in all destination-oriented
skipping to change at page 41, line 36 skipping to change at page 42, line 4
| IPv6 Attached Subnet | | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | Subnet Mask | | IPv6 Attached Subnet | Subnet Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 17 Length: 17
IPv6 Subnet: The IPv6 subnet reachable at the destination. IPv4 Subnet: The IPv6 subnet reachable at the destination.
Subnet Mask: A subnet mask (0-128) to be applied to the IPv6 subnet. Subnet Mask: A subnet mask (0-128) to be applied to the IPv6 subnet.
8.14. Maximum Data Rate (Receive) 8.14. Maximum Data Rate (Receive)
The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the
Peer Initialization ACK signal (Section 7.4), and MAY appear in the Peer Initialization ACK signal (Section 7.4), and MAY appear in the
Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Peer Update (Section 7.5), Destination Up (Section 7.9), Destination
Update (Section 7.13) and Link Characteristics ACK (Section 7.16) Update (Section 7.13) and Link Characteristics ACK (Section 7.16)
signals to indicate the maximum theoretical data rate, in bits per signals to indicate the maximum theoretical data rate, in bits per
skipping to change at page 52, line 27 skipping to change at page 52, line 45
Length: 1 Length: 1
Reserved: This field is currently unused and MUST be set to 0. Reserved: This field is currently unused and MUST be set to 0.
10. Security Considerations 10. Security Considerations
The protocol does not contain any mechanisms for security (e.g., The protocol does not contain any mechanisms for security (e.g.,
authentication or encryption). The protocol assumes that any authentication or encryption). The protocol assumes that any
security would be implemented in the underlying transport (for security would be implemented in the underlying transport (for
example, by use of DTLS or some other mechanism), and is therefore example, by use of TLS or some other mechanism), and is therefore
outside the scope of this document. outside the scope of this document.
11. IANA Considerations 11. IANA Considerations
This section specifies requests to IANA. This section specifies requests to IANA.
11.1. Registrations 11.1. Registrations
This specification defines: This specification defines:
skipping to change at page 56, line 21 skipping to change at page 56, line 43
It is requested that IANA allocate a well-known port number for DLEP It is requested that IANA allocate a well-known port number for DLEP
communication. communication.
11.8. DLEP Multicast Address 11.8. DLEP Multicast Address
It is requested that IANA allocate a multicast address for DLEP It is requested that IANA allocate a multicast address for DLEP
discovery signals. discovery signals.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge and thank the members of the We would like to acknowledge and thank the members of the DLEP design
DLEP design team, who have provided invaluable insight. The members team, who have provided invaluable insight. The members of the
of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning
Henning Rogge. Rogge.
The authors would also like to acknowledge the influence and We would also like to acknowledge the influence and contributions of
contributions of Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang,
Jaewon Kang, Vikram Kaul, Nelson Powell and Victoria Mercieca. Vikram Kaul, Nelson Powell and Victoria Mercieca.
13. References 13. References
13.1. Normative References 13.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M. [RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M.
Adams, "PPP over Ethernet (PPPoE) Extensions for Credit Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
 End of changes. 70 change blocks. 
150 lines changed or deleted 178 lines changed or added

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