< draft-ietf-manet-dlep-12.txt   draft-ietf-manet-dlep-13.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 12, 2015 Expires: November 13, 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 11, 2015 May 12, 2015
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-12 draft-ietf-manet-dlep-13
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 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-
driven communication channel between the router and the modem is driven communication channel between the router and the modem is
necessary. necessary.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 12, 2015. This Internet-Draft will expire on November 13, 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 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . 15 5.4. Common Session Flow . . . . . . . . . . . . . . . . . . . 15
6. DLEP Signal Processing . . . . . . . . . . . . . . . . . . . 16 6. DLEP Signal Structure and 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 . . . . . . . . . . . . . . . . . . . . 19 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
skipping to change at page 3, line 41 skipping to change at page 3, line 41
8.23. Link Characteristics ACK Timer . . . . . . . . . . . . . 48 8.23. Link Characteristics ACK Timer . . . . . . . . . . . . . 48
9. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 48 9. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Credit-Windowing Signals . . . . . . . . . . . . . . . . 49 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 . . . . . . . . . . . . . . . 50 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 . . . . . . . . . . . . . . . . . . . 52 9.2.3. Credit Request . . . . . . . . . . . . . . . . . . . 52
10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 53
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 53 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 . . . . . . . . . . . . . . . . 54
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 . . . . . . . . . . . . . 56
11.6. DLEP Extensions Registrations . . . . . . . . . . . . . 56 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 . . . . . . . . . . . . . . . . . 57
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 57 13.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 57 Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 57
A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 57 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2. Session Initialization . . . . . . . . . . . . . . . . . 57 A.2. Session Initialization . . . . . . . . . . . . . . . . . 58
A.3. Session Initialization - Refused . . . . . . . . . . . . 58 A.3. Session Initialization - Refused . . . . . . . . . . . . 59
A.4. Router Changes IP Addresses . . . . . . . . . . . . . . . 59 A.4. Router Changes IP Addresses . . . . . . . . . . . . . . . 59
A.5. Modem Changes Session-wide Metrics . . . . . . . . . . . 59 A.5. Modem Changes Session-wide Metrics . . . . . . . . . . . 59
A.6. Router Terminates Session . . . . . . . . . . . . . . . . 59 A.6. Router Terminates Session . . . . . . . . . . . . . . . . 60
A.7. Modem Terminates Session . . . . . . . . . . . . . . . . 60 A.7. Modem Terminates Session . . . . . . . . . . . . . . . . 60
A.8. Session Heartbeats . . . . . . . . . . . . . . . . . . . 60 A.8. Session Heartbeats . . . . . . . . . . . . . . . . . . . 61
A.9. Router Detects a Heartbeat timeout . . . . . . . . . . . 61 A.9. Router Detects a Heartbeat timeout . . . . . . . . . . . 62
A.10. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 62 A.10. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 63
Appendix B. Destination Specific Signal Flows . . . . . . . . . 62 Appendix B. Destination Specific Signal Flows . . . . . . . . . 63
B.1. Common Destination Signaling . . . . . . . . . . . . . . 62 B.1. Common Destination Signaling . . . . . . . . . . . . . . 63
B.2. Multicast Destination Signaling . . . . . . . . . . . . . 63 B.2. Multicast Destination Signaling . . . . . . . . . . . . . 64
B.3. Link Characteristics Request . . . . . . . . . . . . . . 63 B.3. Link Characteristics Request . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
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, 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
datarate varies with respect to individual destinations on a link, datarate vary with respect to individual destinations on a link, and
and with the type of traffic being sent. As an example, consider the with the type of traffic being sent. As an example, consider the
case of an 802.11g access point, serving 2 associated laptop case of an 802.11 access point, serving 2 associated laptop
computers. In this environment, the answer to the question "What is computers. In this environment, the answer to the question "What is
the datarate on the 802.11g link?" is "It depends on which associated the datarate on the 802.11 link?" is "It depends on which associated
laptop we're talking about, and on what kind of traffic is being laptop we're talking about, and on what kind of traffic is being
sent." While the first laptop, being physically close to the access sent." While the first laptop, being physically close to the access
point, may have a datarate of 54Mbps for unicast traffic, the other point, may have a datarate of 54Mbps for unicast traffic, the other
laptop, being relatively far away, or obstructed by some object, can laptop, being relatively far away, or obstructed by some object, can
simultaneously have a datarate of only 32Mbps for unicast. However, simultaneously have a datarate of only 32Mbps for unicast. However,
for multicast traffic sent from the access point, all traffic is sent for multicast traffic sent from the access point, all traffic is sent
at the base transmission rate (which is configurable, but depending at the base transmission rate (which is configurable, but depending
on the model of the access point, is usually 24Mbps or less). on the model 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
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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
neighbor (or loss of an existing one) is signaled, as opposed to a neighbor (or loss of an existing one) is signaled, as opposed to a
paradigm driven by timers and/or interface state. paradigm driven by timers and/or interface state.
Another complicating factor for mobile networks are the different Another complicating factor for mobile networks are the different
methods of physically connecting the modem devices to the router. methods of physically connecting the modem devices to the router.
Modems can be deployed as an interface card in a router's chassis, or Modems can be deployed as an interface card in a router's chassis, or
as a standalone device connected to the router via Ethernet or serial as a standalone device connected to the router via Ethernet or serial
link. In the case of Ethernet or serial attachment, with existing link. In the case of Ethernet attachment, with existing protocols
protocols and techniques, routing software cannot be aware of and techniques, routing software cannot be aware of convergence
convergence events occurring on the radio link (e.g., acquisition or events occurring on the radio link (e.g., acquisition or loss of a
loss of a potential routing neighbor), nor can the router be aware of potential routing neighbor), nor can the router be aware of the
the actual capacity of the link. This lack of awareness, along with actual capacity of the link. This lack of awareness, along with the
the variability in datarate, leads to a situation where finding the variability in datarate, leads to a situation where finding the
(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.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
network accessed via the DLEP modem) is handled in IP networks by network accessed via the DLEP modem) is handled in IP networks by
deriving a Layer 2 MAC address based on the Layer 3 address. deriving a Layer 2 MAC address based on the Layer 3 address.
Leveraging on this scheme, multicast traffic is supported in DLEP Leveraging on this scheme, multicast traffic is supported in DLEP
simply by treating the derived MAC address as any other 'destination' simply by treating the derived MAC address as any other 'destination'
(albeit a logical one) in the network. To support these logical (albeit a logical one) in the network. To support these logical
destinations, one of the DLEP participants (typically, the router) destinations, one of the DLEP participants (typically, the router)
informs the other as to the existence of the logical destination. informs the other as to the existence of the logical destination.
The modem, once it is aware of the existence of this logical The modem, once it is aware of the existence of this logical
destination, reports link characteristics just as it would for any destination, reports link characteristics just as it would for any
other destination in the network. The specific algorithms a modem other destination in the network. The specific algorithms a modem
would use to derive metrics on multicast (or logical) destinations is would use to derive metrics on multicast (or logical) destinations
outside the scope of this specification, and is left to specific are outside the scope of this specification, and is left to specific
implementations to decide. implementations to decide.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14, RFC 2119 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14, RFC 2119 [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 use a discovery technique to locate each are locally connected) can use a discovery technique to locate 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 uses 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 uses 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
reference a logical destination, as in a derived multicast MAC reference a logical destination, as in a derived multicast MAC
address, as well as a physical device. As destinations are address, as well as a physical device. As destinations are
discovered, DLEP routers and modems build an information base on discovered, DLEP routers and modems build an information base on
skipping to change at page 11, line 50 skipping to change at page 11, line 50
4. Metrics 4. Metrics
DLEP includes the ability for the router and modem to communicate DLEP includes the ability for the router and modem to communicate
metrics that reflect the characteristics (e.g., datarate, latency) of metrics that reflect the characteristics (e.g., datarate, latency) of
the variable-quality link in use. DLEP does NOT specify how a given the variable-quality link in use. DLEP does NOT specify how a given
metric value is to be calculated, rather, the protocol assumes that metric value is to be calculated, rather, the protocol assumes that
metrics have been calculated with a 'best effort', incorporating all metrics have been calculated with a 'best effort', incorporating all
pertinent data that is available to the modem device. pertinent data that is available to the modem device.
As mentioned in the introduction section of this document, DLEP DLEP allows for metrics to be sent within two contexts - metrics for
allows for metrics to be sent within two contexts - metrics for a a specific destination within the network (e.g., a specific router),
specific destination within the network (e.g., a specific router),
and 'modem-wide' (those that apply to all destinations accessed via and 'modem-wide' (those that apply to all destinations accessed via
the modem). Most metrics can be further subdivided into transmit and the modem). Most metrics can be further subdivided into transmit and
receive metrics. Metrics supplied on DLEP Peer signals are, by receive metrics. Metrics supplied on DLEP Peer signals are, by
definition, modem-wide; metrics supplied on Destination signals are, definition, modem-wide; metrics supplied on Destination signals are,
by definition, used for the specific logical destination only. by definition, used for the specific logical destination only.
DLEP modem implementations MUST announce all supported metric items, DLEP modem implementations MUST announce all supported metric items,
and provide default values for those metrics, in the Peer and provide default values for those metrics, in the Peer
Initialization ACK signal (Section 7.4). In order to introduce a new Initialization ACK signal (Section 7.4). In order to introduce a new
metric type, DLEP modem implementations MUST terminate the session metric type, DLEP modem implementations MUST terminate the session
with the router (via the Peer Terminate signal (Section 7.7)), and with the router (via the Peer Terminate signal (Section 7.7)), and
re-establish the session. allow for session re-establishment.
It is left to implementations to choose sensible default values based It is left to implementations to choose sensible default values based
on their specific characteristics. Modems having static (non- on their specific characteristics. Modems having static (non-
changing) link metric characteristics MAY report metrics only once changing) link metric characteristics MAY report metrics only once
for a given destination (or once on a modem-wide basis, if all for a given destination (or once on a modem-wide basis, if all
connections via the modem are of this static nature). connections via the modem are of this static nature).
The approach of allowing for different contexts for metric data The approach of allowing for different contexts for metric data
increases both the flexibility and the complexity of using metric increases both the flexibility and the complexity of using metric
data. This document details the mechanism whereby the data is data. This document details the mechanism whereby the data is
transmitted, however, the specific algorithms (precedence, etc.) for transmitted, however, the specific algorithms (precedence, etc.) for
utilizing the dual-context metrics is out of scope and not addressed utilizing the dual-context metrics are out of scope and not addressed
by this document. by this document.
4.1. Mandatory Metrics 4.1. Mandatory Metrics
As mentioned above, DLEP modem implementations MUST announce all As mentioned above, DLEP modem implementations MUST announce all
supported metric items during session initialization. However, an supported metric items during session initialization. However, an
implementation MUST include the following list of metrics: implementation MUST include the following list of metrics:
o Maximum Data Rate (Receive) (Section 8.14) o Maximum Data Rate (Receive) (Section 8.14)
skipping to change at page 13, line 4 skipping to change at page 12, line 51
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.
Discovery is initiated in the DLEP modem by sending the Peer Discovery is initiated in the DLEP modem by sending the Peer
Discovery Signal (Section 7.1) to a well-known multicast address. Discovery Signal (Section 7.1) to a well-known multicast address.
However, support for receipt and processing of the signal is optional However, support for receipt and processing of the signal is optional
in the router (see Appendix A and B for flow diagrams of the in the router (see Appendix A for flow diagrams of the discovery
discovery signal). Due to the optional (on the router) support for signal). Due to the optional (on the router) support for discovery,
discovery, normal session flow is described for both the 'Discovery normal session flow is described for both the 'Discovery case', and
case', and the 'Configured case'. Again, for modem implementations the 'Configured case'. Again, for modem implementations of DLEP,
of DLEP, support of Discovery is mandatory; therefore, that is the support of Discovery is mandatory; therefore, that is the only case
only case to be described. 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 43 skipping to change at page 15, line 43
Destination Update signal (Section 7.13). The information on a given Destination Update signal (Section 7.13). The information on a given
destination will persist in the router's information base until (1) a destination will persist in the router's information base until (1) a
Destination Down signal is received, indicating that the modem has Destination Down signal is received, indicating that the modem has
lost contact with the remote node, or (2) the router/modem session lost contact with the remote node, or (2) the router/modem session
terminates, indicating that the router has lost contact with its own terminates, indicating that the router has lost contact with its own
local modem. local modem.
Metrics can be expressed within the context of a specific destination Metrics can be expressed within the context of a specific destination
via the Destination Update signal, or on a modem-wide basis via the via the Destination Update signal, or on a modem-wide basis via the
Peer Update signal. In cases where metrics are provided at peer Peer Update signal. In cases where metrics are provided at peer
level, the receiver MUST propagate the metrics to all destinations in level, the receiver MUST propagate the metrics to all entries in its
its information base that are accessed via the originator. A DLEP information base for destinations that are accessed via the
participant MAY send metrics both in a router/modem session context originator. A DLEP participant MAY send metrics both in a router/
(via the Peer Update signal) and a specific destination context (via modem session context (via the Peer Update signal) and a specific
Destination Update) at any time. The heuristics for applying destination context (via Destination Update) at any time. The
received metrics is left to implementations. heuristics for applying 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 Signal Processing 6. DLEP Signal Structure and Processing
Communication between DLEP peers consists of a bidirectional stream Communication between DLEP peers consists of a bidirectional stream
of signals (messages), each signal consisting of a signal header and of signals (messages), each signal consisting of a signal header and
an unordered list of data items. Signal headers consist of Type and an unordered list of data items. Signal headers consist of Type and
Length information, while data items are encoded as TLV (Type-Length- Length information, while data items are encoded as TLV (Type-Length-
Value) structures. In this document, the data items following the Value) structures. In this document, the data items following the
signal header are described as being 'contained in' the signal. signal header are described as being 'contained in' the signal.
All integer values structures MUST be in network byte-order. All integer values structures MUST be in network byte-order.
skipping to change at page 16, line 44 skipping to change at page 16, line 44
The DLEP signal header contains the following fields: The DLEP signal header contains the following fields:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Length | | Signal Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DLEP Signal Header Figure 3: DLEP Signal Header
Signal Type: One of the DLEP Signal Type values defined in this Signal Type: An 8-bit unsigned integer containing one of the DLEP
document. Signal Type values defined in this document.
Length: The length, expressed as a 16-bit unsigned integer, of all Length: The length, expressed as a 16-bit unsigned integer, of all
of the DLEP data items associated with this signal. This length of the DLEP data items associated with this signal. This length
does not include the length of the header itself does not include the length of the header itself
The DLEP Signal Header is immediately followed by one or more DLEP The DLEP Signal Header is immediately followed by one or more DLEP
data items, encoded in TLVs, as defined in this document. data items, encoded in TLVs, as defined in this document.
6.2. DLEP Generic Data Item 6.2. DLEP Generic Data Item
skipping to change at page 19, line 51 skipping to change at page 19, line 51
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
items in a Peer Initialization signal, the receiver of the signal items in a Peer Initialization 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.
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 heuristics 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_INIT in Table 1. 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)
skipping to change at page 22, line 46 skipping to change at page 22, line 46
modem that changes its Maximum Data Rate (Receive) for all modem that changes its Maximum Data Rate (Receive) for all
destinations MAY reflect that change via a Peer Update signal to its destinations MAY reflect that change via a Peer Update signal to its
attached router(s). attached router(s).
Concerning Layer 3 addresses, if the modem is capable of Concerning Layer 3 addresses, if the modem is capable of
understanding and forwarding this information (via proprietary understanding and forwarding this information (via proprietary
mechanisms), the address update would prompt any remote DLEP modems mechanisms), the address update would prompt any remote DLEP modems
(DLEP-enabled modems in a remote node) to issue a Destination Update (DLEP-enabled modems in a remote node) to issue a Destination Update
signal (Section 7.13) to their local routers with the new (or signal (Section 7.13) to their local routers with the new (or
deleted) addresses. Modems that do not track Layer 3 addresses deleted) addresses. Modems that do not track Layer 3 addresses
SHOULD silently parse and ignore the Peer Update signal. Modems that SHOULD silently parse and ignore Layer 3 data items. The Peer Update
track Layer 3 addresses MUST acknowledge the Peer Update with a Peer Signal MUST be acknowledged with a Peer Update ACK signal
Update ACK signal (Section 7.6). (Section 7.6).
If metrics are supplied with the Peer Update signal (e.g., Maximum If metrics are supplied with the Peer Update signal (e.g., Maximum
Data Rate), these metrics are considered to be modem-wide, and Data Rate), these metrics are considered to be modem-wide, and
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
skipping to change at page 24, line 44 skipping to change at page 24, line 44
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_TERM in Table 1. 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 of 'Unknown reason for Peer Termination'
implying graceful termination, had been received. has been received.
A Peer Termination signal MUST be acknowledged by the receiver A Peer Termination signal MUST be acknowledged by the receiver
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.
skipping to change at page 27, line 6 skipping to change at page 27, line 6
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)
A receiver of a Destination Up ACK signal without a Status data item A receiver of a Destination Up ACK signal without a Status data item
MUST behave as if a Status data item with status code 'Success' had MUST behave as if a Status data item with status code 'Success' had
been received. Implementations are free to define retry heurestics been received. Implementations are free to define retry heuristics
when receiving a Destination Up ACK signal indicating an error. when receiving a Destination Up ACK signal indicating an error.
7.11. Destination Down Signal 7.11. Destination Down Signal
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
skipping to change at page 28, line 4 skipping to change at page 28, line 4
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)
A receiver of a Destination Down ACK signal without a Status data A receiver of a Destination Down 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'
had been received. Implementations are free to define retry had been received. Implementations are free to define retry
heurestics when receiving a Destination Down ACK signal indicating an heuristics when receiving a Destination Down ACK signal indicating an
error. error.
7.13. Destination Update Signal 7.13. Destination Update Signal
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)
skipping to change at page 33, line 32 skipping to change at page 33, line 32
Support of this draft is indicated by setting the Major Version to Support of this draft is indicated by setting the Major Version to
'1', and the Minor Version to '0' (i.e. Version 1.0). '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. For the Peer Termination
acknowledgement from either the modem or the router, to indicate the Signal (Section 7.7), the Status data item indicates a reason for the
success or failure of the previously received signal. termination. For all acknowledgement signals, the Status data item
is used to indicate the success or failure of the previously received
signal.
The status data item includes an optional Text field that can be used The status data item includes an optional Text field that can be used
to provide a textual description of the status. The use of the Text to provide a textual description of the status. The use of the Text
field is entirely up to the receiving implementation, i.e., it could field is entirely up to the receiving implementation, i.e., it could
be output to a log file or discarded. If no Text field is supplied be output to a log file or discarded. If no Text field is supplied
with the Status data item, the Length field MUST be set to 1. with the Status data item, the Length field MUST be set to 1.
The Status data item contains the following fields: The Status data item contains the following fields:
0 1 2 3 0 1 2 3
skipping to change at page 37, line 7 skipping to change at page 37, line 7
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.
The Interval is used to specify a period (in seconds) for Heartbeat The Interval is used to specify a period (in seconds) for Heartbeat
signals (Section 7.14). By specifying an Interval value of 0, signals (Section 7.14). By specifying an Interval value of 0,
implementations MAY indicates the desire to disable Heartbeat signals implementations MAY indicate the desire to disable Heartbeat signals
entirely (i.e., the Interval is set to an infinite value). However, entirely (i.e., the Interval is set to an infinite value). However,
it is strongly recommended that implementations use non 0 timer it is strongly recommended that implementations use non-0 timer
values. Implementations MUST implement heuristics such that DLEP values. Implementations MUST implement heuristics such that DLEP
signals sent/received reset the timer interval. signals sent/received reset the timer interval.
A DLEP session will be considered inactive, and MUST be torn down, A DLEP session will be considered inactive, and MUST be torn down,
via the Peer Termination procedure, by an implementation detecting via the Peer Termination procedure, by an implementation detecting
that two (2) Heartbeat intervals have transpired without receipt of that two (2) Heartbeat intervals have transpired without receipt of
any DLEP signals. any DLEP signals.
The Heartbeat Interval data item contains the following fields: The Heartbeat Interval data item contains the following fields:
skipping to change at page 39, line 48 skipping to change at page 39, line 48
| | | Indicator | | | | | Indicator | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 5 Length: 5
Add/Drop: Value indicating whether this is a new or existing address Add/Drop: Value indicating whether this is a new or existing address
(1), or a withdrawal of an address (0). (1), or a withdrawal of an address (0). Values other than 0 or 1
MUST be considered as invalid.
IPv4 Address: The IPv4 address of the destination or peer. IPv4 Address: The IPv4 address of the destination or peer.
8.11. IPv6 Address 8.11. IPv6 Address
The IPv6 Address data item MAY appear in the Peer Update The IPv6 Address data item MAY appear in the Peer Update
(Section 7.5), Destination Up (Section 7.9) and Destination Update (Section 7.5), Destination Up (Section 7.9) and Destination Update
(Section 7.13) signals. When included in Destination signals, this (Section 7.13) signals. When included in Destination signals, this
data item contains the IPv6 address of the destination. When data item contains the IPv6 address of the destination. When
included in the Peer Update signal, this data item contains the IPv6 included in the Peer Update signal, this data item contains the IPv6
skipping to change at page 40, line 38 skipping to change at page 40, line 38
| IPv6 Address | | IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address | | IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 17 Length: 17
Add/Drop: Value indicating whether this is a new or existing address Add/Drop: Value indicating whether this is a new or existing address
(1), or a withdrawal of an address (0). (1), or a withdrawal of an address (0). Values other than 0 or 1
MUST be considered as invalid.
IPv6 Address: IPv6 Address of the destination or peer. IPv6 Address: IPv6 Address of the destination or peer.
8.12. IPv4 Attached Subnet 8.12. 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, and MAY appear in the an IPv4 subnet (e.g., a stub network) attached, or that it has become
Destination Up (Section 7.9) and Destination Update (Section 7.13) aware of an IPv4 subnet being present at a remote destination. The
signals. Once an IPv4 Subnet has been declared on a device, the IPv4 Attached Subnet data item MAY appear in the Destination Up
declaration can NOT be withdrawn without terminating the destination (Section 7.9) and Destination Update (Section 7.13) signals. Once an
(via the Destination Down signal (Section 7.11)) and re-issuing the IPv4 Subnet has been declared on a device, the declaration can NOT be
Destination Up signal. withdrawn without terminating the destination (via the Destination
Down signal (Section 7.11)) and re-issuing the Destination Up signal.
The DLEP IPv4 Attached Subnet data item contains the following The DLEP IPv4 Attached Subnet data item contains the following
fields: 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 | IPv4 Attached Subnet | |Data Item Type | Length | IPv4 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Attached Subnet | Subnet Mask | | IPv4 Attached Subnet | Prefix Len. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 5 Length: 5
IPv4 Subnet: The IPv4 subnet reachable at the destination. IPv4 Subnet: The IPv4 subnet reachable at the destination.
Subnet Mask: A subnet mask (0-32) to be applied to the IPv4 subnet. Prefix Length: Length of the prefix (0-32) for the IPv4 subnet.
8.13. IPv6 Attached Subnet 8.13. 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, and MAY appear in the an IPv6 subnet (e.g., a stub network) attached, or that it has become
Destination Up (Section 7.9) and Destination Update (Section 7.13) aware of an IPv6 subnet being present at a remote destination. The
signals. As in the case of the IPv4 attached Subnet data item above, IPv6 Attached Subnet data item MAY appear in the Destination Up
once an IPv6 attached subnet has been declared, it can NOT be (Section 7.9) and Destination Update (Section 7.13) signals. As in
withdrawn without terminating the destination (via the Destination the case of the IPv4 attached Subnet data item above, once an IPv6
Down signal (Section 7.11)) and re-issuing the Destination Up signal. attached subnet has been declared, it can NOT be withdrawn without
terminating the destination (via the Destination Down signal
(Section 7.11)) and re-issuing the Destination Up signal.
The DLEP IPv6 Attached Subnet data item contains the following The DLEP IPv6 Attached Subnet data item contains the following
fields: 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 | IPv6 Attached Subnet | | Data Item Type| Length | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Prefix Len. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 17 Length: 17
IPv4 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. Prefix Length: Length of the prefix (0-128) for 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
second, that can be achieved while receiving data on the link. second, that can be achieved while receiving data on the link.
skipping to change at page 46, line 17 skipping to change at page 46, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length | RESR | | Data Item Type| Length | RESR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 1 Length: 1
Resources (Receive): An 8-bit integer percentage, 0-100, Resources (Receive): An 8-bit integer percentage, 0-100,
representing the amount of resources allocated to receiving data. representing the amount of resources allocated to receiving data.
Any value greater than 100 MUST be considered as invalid.
If a device cannot calculate RESR, this data item SHOULD NOT be If a device cannot calculate RESR, this data item SHOULD NOT be
issued. issued.
8.20. Resources (Transmit) 8.20. Resources (Transmit)
The Resources (Transmit) (REST) data item MAY appear in the Peer The Resources (Transmit) (REST) data item MAY appear in the Peer
Initialization ACK signal (Section 7.4), Peer Update (Section 7.5), Initialization ACK signal (Section 7.4), Peer Update (Section 7.5),
Destination Up (Section 7.9), Destination Update (Section 7.13) and Destination Up (Section 7.9), Destination Update (Section 7.13) and
Link Characteristics ACK (Section 7.16) signals to indicate the Link Characteristics ACK (Section 7.16) signals to indicate the
skipping to change at page 46, line 47 skipping to change at page 46, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length | REST | | Data Item Type| Length | REST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 1 Length: 1
Resources (Transmit): An 8-bit integer percentage, 0-100, Resources (Transmit): An 8-bit integer percentage, 0-100,
representing the amount of resources allocated to transmitting representing the amount of resources allocated to transmitting
data. data. Any value greater than 100 MUST be considered as invalid.
If a device cannot calculate REST, this data item SHOULD NOT be If a device cannot calculate REST, this data item SHOULD NOT be
issued. issued.
8.21. Relative Link Quality (Receive) 8.21. Relative Link Quality (Receive)
The Relative Link Quality (Receive) (RLQR) data item MAY appear in The Relative Link Quality (Receive) (RLQR) data item MAY appear in
the Peer Initialization ACK signal (Section 7.4), Peer Update the Peer Initialization ACK signal (Section 7.4), Peer Update
(Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.5), Destination Up (Section 7.9), Destination Update
(Section 7.13) and Link Characteristics ACK (Section 7.16) signals to (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to
skipping to change at page 47, line 28 skipping to change at page 47, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length | RLQR | | Data Item Type| Length | RLQR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 1 Length: 1
Relative Link Quality (Receive): A non-dimensional 8-bit integer, Relative Link Quality (Receive): A non-dimensional 8-bit integer,
1-100, representing relative link quality. A value of 100 1-100, representing relative link quality. A value of 100
represents a link of the highest quality. represents a link of the highest quality. Any value greater than
100 MUST be considered as invalid.
If a device cannot calculate the RLQR, this data item SHOULD NOT be If a device cannot calculate the RLQR, this data item SHOULD NOT be
issued. issued.
8.22. Relative Link Quality (Transmit) 8.22. Relative Link Quality (Transmit)
The Relative Link Quality (Transmit) (RLQT) data item MAY appear in The Relative Link Quality (Transmit) (RLQT) data item MAY appear in
the Peer Initialization ACK signal (Section 7.4), Peer Update the Peer Initialization ACK signal (Section 7.4), Peer Update
(Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.5), Destination Up (Section 7.9), Destination Update
(Section 7.13) and Link Characteristics ACK (Section 7.16) signals to (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to
skipping to change at page 47, line 51 skipping to change at page 48, line 4
The Relative Link Quality (Transmit) data item contains the following The Relative Link Quality (Transmit) data item contains the following
fields: fields:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length | RLQT | | Data Item Type| Length | RLQT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 1 Length: 1
Relative Link Quality (Transmit): A non-dimensional 8-bit integer, Relative Link Quality (Transmit): A non-dimensional 8-bit integer,
1-100, representing relative link quality. A value of 100 1-100, representing relative link quality. A value of 100
represents a link of the highest quality. represents a link of the highest quality. Any value greater than
100 MUST be considered as invalid.
If a device cannot calculate the RLQT, this data item SHOULD NOT be If a device cannot calculate the RLQT, this data item SHOULD NOT be
issued. issued.
8.23. Link Characteristics ACK Timer 8.23. Link Characteristics ACK Timer
The Link Characteristics ACK Timer data item MAY appear in the Link The Link Characteristics ACK Timer data item MAY appear in the Link
Characteristics Request signal (Section 7.15) to indicate the desired Characteristics Request signal (Section 7.15) to indicate the desired
number of seconds to the sender will wait for a response to the number of seconds the sender will wait for a response to the request.
request. If this data item is omitted, implementations supporting If this data item is omitted, implementations supporting the Link
the Link Characteristics Request SHOULD choose a default value. Characteristics Request SHOULD choose a default value.
The Link Characteristics ACK Timer data item contains the following The Link Characteristics ACK Timer data item contains the following
fields: fields:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length | Interval | | Data Item Type| Length | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD
Length: 1 Length: 1
Interval: 0 = Do NOT use timeouts for this Link Characteristics Interval: 0 = Do NOT use timeouts for this Link Characteristics
request. Non-zero = Interval, in seconds, to wait before request. Non-zero = Interval, in seconds, to wait before
considering this Link Characteristics Request has been lost. considering this Link Characteristics Request lost.
9. Credit-Windowing 9. Credit-Windowing
DLEP includes an OPTIONAL Protocol Extension for a credit-windowing DLEP includes an OPTIONAL Protocol Extension for a credit-windowing
scheme analogous to the one documented in [RFC5578]. In this scheme, scheme analogous to the one documented in [RFC5578]. In this scheme,
traffic between the router and modem is treated as two unidirectional traffic between the router and modem is treated as two unidirectional
windows. This document identifies these windows as the 'Modem windows. This document identifies these windows as the 'Modem
Receive Window' (MRW), and the 'Router Receive Window' (RRW). Receive Window' (MRW), and the 'Router Receive Window' (RRW).
If the OPTIONAL credit-windowing extension is used, credits MUST be If the OPTIONAL credit-windowing extension is used, credits MUST be
skipping to change at page 48, line 48 skipping to change at page 49, line 4
DLEP includes an OPTIONAL Protocol Extension for a credit-windowing DLEP includes an OPTIONAL Protocol Extension for a credit-windowing
scheme analogous to the one documented in [RFC5578]. In this scheme, scheme analogous to the one documented in [RFC5578]. In this scheme,
traffic between the router and modem is treated as two unidirectional traffic between the router and modem is treated as two unidirectional
windows. This document identifies these windows as the 'Modem windows. This document identifies these windows as the 'Modem
Receive Window' (MRW), and the 'Router Receive Window' (RRW). Receive Window' (MRW), and the 'Router Receive Window' (RRW).
If the OPTIONAL credit-windowing extension is used, credits MUST be If the OPTIONAL credit-windowing extension is used, credits MUST be
granted by the receiver on a given window - that is, on the 'Modem granted by the receiver on a given window - that is, on the 'Modem
Receive Window' (MRW), the modem is responsible for granting credits Receive Window' (MRW), the modem is responsible for granting credits
to the router, allowing it (the router) to send data to the modem. to the router, allowing it (the router) to send data to the modem.
Likewise, the router is responsible for granting credits on the RRW, Likewise, the router is responsible for granting credits on the RRW,
which allows the modem to send data to the router. which allows the modem to send data to the router.
Credits are managed on a destination-specific basis; that is, Credits are managed on a destination-specific basis; that is,
separate credit counts are maintained for each destination requiring separate credit counts are maintained for each destination requiring
the service. Credits do not apply to the DLEP session that exists the service. Credits do not apply to the DLEP session that exists
between routers and modems. between routers and modems.
Credits represent the number of octets, or an increment in the number
of octets, that MAY be sent on the given window. When the number of
available credits reaches 0, a sender MUST stop sending data, until
additional credits are supplied.
If a peer is able to support the OPTIONAL credit-windowing extension If a peer is able to support the OPTIONAL credit-windowing extension
then it MUST include a Extensions Supported data item (Section 8.7) then it MUST include an Extensions Supported data item (Section 8.7)
including the value DLEP_EXT_CREDITS (value TBD) in the appropriate including the value DLEP_EXT_CREDITS (value TBD) in the appropriate
Peer Initialization or Peer Initialization ACK signal. Peer Initialization or Peer Initialization ACK signal.
9.1. Credit-Windowing Signals 9.1. Credit-Windowing Signals
The credit-windowing extension introduces no additional DLEP signals. The credit-windowing extension introduces no additional DLEP signals.
However, if a peer has advertised during session initialization that However, if a peer has advertised during session initialization that
it supports the credit-windowing extension then the following DLEP it supports the credit-windowing extension then the following DLEP
signals MAY contain additional credit-windowing data items: signals MAY contain additional credit-windowing data items:
skipping to change at page 50, line 4 skipping to change at page 50, line 12
data item, the Destination Update signal MUST contain one of each of data item, the Destination Update signal MUST contain one of each of
the following data items: the following data items:
o Credit Window Status (Section 9.2.2) o Credit Window Status (Section 9.2.2)
If the corresponding Destination Up signal contained the Credit Grant If the corresponding Destination Up signal contained the Credit Grant
data item, the Destination Update signal MAY contain one of each of data item, the Destination Update signal MAY contain one of each of
the following data items: the following data items:
o Credit Grant (Section 9.2.1) o Credit Grant (Section 9.2.1)
o Credit Request (Section 9.2.3) o Credit Request (Section 9.2.3)
9.2. Credit-Windowing Data Items 9.2. Credit-Windowing Data Items
The credit-windowing extension introduces 3 additional data items. The credit-windowing extension introduces 3 additional data items.
If a peer has advertised during session initialization that it If a peer has advertised during session initialization that it
supports the credit-windowing extension then it MUST correctly supports the credit-windowing extension then it MUST correctly
process the following data items without error. process the following data items.
+------------+-----------------------+----------------+ +------------+-----------------------+----------------+
| Data Item | Description | Section | | Data Item | Description | Section |
+------------+-----------------------+----------------+ +------------+-----------------------+----------------+
| TBD | Credit Grant | Section 9.2.1 | | TBD | Credit Grant | Section 9.2.1 |
| TBD | Credit Window Status | Section 9.2.2 | | TBD | Credit Window Status | Section 9.2.2 |
| TBD | Credit Request | Section 9.2.3 | | TBD | Credit Request | Section 9.2.3 |
+------------+-----------------------+----------------+ +------------+-----------------------+----------------+
9.2.1. Credit Grant 9.2.1. Credit Grant
 End of changes. 61 change blocks. 
104 lines changed or deleted 120 lines changed or added

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