< draft-ietf-manet-dlep-03.txt   draft-ietf-manet-dlep-04.txt >
Mobile Ad hoc Networks Working S. Ratliff Mobile Ad hoc Networks Working S. Ratliff
Group B. Berry Group B. Berry
Internet-Draft G. Harrison Internet-Draft G. Harrison
Intended status: Standards Track D. Satterwhite Intended status: Standards Track Cisco Systems
Expires: March 3, 2013 Cisco Systems Expires: September 22, 2013 D. Satterwhite
Broadcom
S. Jury S. Jury
NetApp NetApp
August 30, 2012 March 25, 2013
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-03 draft-ietf-manet-dlep-04
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 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 10 5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 10
6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . . 10 6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . . 10
7. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 12 7. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 12
8. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 13 8. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 13
9. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . . 13 9. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Identification . . . . . . . . . . . . . . . . . . . . . . 14 9.1 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 14
9.2 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 15 9.2 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.3 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 15
9.4 MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 16 9.4 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 16
9.5 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 17 9.5 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 17
9.6 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 18 9.6 Maximum Data Rate (Receive) . . . . . . . . . . . . . . . . 17
9.7 Maximum Data Rate . . . . . . . . . . . . . . . . . . . . . 18 9.7 Maximum Data Rate (Transmit) . . . . . . . . . . . . . . . 18
9.8 Current Data Rate . . . . . . . . . . . . . . . . . . . . . 19 9.8 Current Data Rate (Receive) . . . . . . . . . . . . . . . . 19
9.9 Expected Forwarding Time . . . . . . . . . . . . . . . . . 20 9.9 Current Data Rate (Transmit) . . . . . . . . . . . . . . . 20
9.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.10 Expected Forwarding Time . . . . . . . . . . . . . . . . . 21
9.11 Resources . . . . . . . . . . . . . . . . . . . . . . . . 21 9.11 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.12 Relative Link Quality . . . . . . . . . . . . . . . . . . 22 9.12 Resources (Receive) . . . . . . . . . . . . . . . . . . . 22
9.13 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.13 Resources (Transmit) . . . . . . . . . . . . . . . . . . . 22
9.14 Heartbeat Interval/Threshold . . . . . . . . . . . . . . . 23 9.14 Relative Link Quality (Receive) . . . . . . . . . . . . . 23
9.15 Link Characteristics ACK Timer . . . . . . . . . . . . . . 24 9.15 Relative Link Quality (Transmit) . . . . . . . . . . . . . 24
9.16 Credit Window Status . . . . . . . . . . . . . . . . . . . 24 9.16 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.17 Credit Grant Request . . . . . . . . . . . . . . . . . . . 25 9.17 Heartbeat Interval/Threshold . . . . . . . . . . . . . . . 25
9.18 Credit Request . . . . . . . . . . . . . . . . . . . . . . 26 9.18 Link Characteristics ACK Timer . . . . . . . . . . . . . . 26
10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 27 9.19 Credit Window Status . . . . . . . . . . . . . . . . . . . 26
10.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 27 9.20 Credit Grant Request . . . . . . . . . . . . . . . . . . . 27
11. Peer Discovery Message . . . . . . . . . . . . . . . . . . . . 28 9.21 Credit Request . . . . . . . . . . . . . . . . . . . . . . 28
12. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 28
13. Peer Offer ACK Message . . . . . . . . . . . . . . . . . . . . 29
14. Peer Update Message . . . . . . . . . . . . . . . . . . . . . 30
15. Peer Update ACK Message . . . . . . . . . . . . . . . . . . . 31
16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 31
17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 31
18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 32
19. Neighbor Up ACK Message . . . . . . . . . . . . . . . . . . . 32
20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 33
21. Neighbor Down ACK Message . . . . . . . . . . . . . . . . . . 33
22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 34
23. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 34
24. Link Characteristics Request Message . . . . . . . . . . . . . 35
25. Link Characteristics ACK Message . . . . . . . . . . . . . . . 36
26. Security Considerations . . . . . . . . . . . . . . . . . . . 36
27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
27.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 36
27.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 37
27.3 Signal (Message) TLV Type Registration . . . . . . . . . . 37
27.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 38
27.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 38
27.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 38
30. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 38
30.1 Peer Level Message Flows . . . . . . . . . . . . . . . . . 38
30.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 38
30.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 39
30.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 40
30.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 40
30.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 41
30.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 41
30.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 42
30.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 42
30.2 Neighbor Specific Message Flows . . . . . . . . . . . . . 42
30.2.1 Modem Neighbor Up Lost . . . . . . . . . . . . . . . . 43
30.2.2 Router Detects Duplicate Neighbor Ups . . . . . . . . 43
30.2.3 Neighbor Up, No Layer 3 Addresses . . . . . . . . . . 44
30.2.4 Neighbor Up with IPv4, No IPv6 . . . . . . . . . . . . 44
30.2.5 Neighbor Up with IPv4 and IPv6 . . . . . . . . . . . . 44
30.2.6 Neighbor Session Success . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . . . 45
Informative References . . . . . . . . . . . . . . . . . . . . . . 46
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 29
10.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 29
11. Peer Discovery Message . . . . . . . . . . . . . . . . . . . . 30
12. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 31
13. Peer Offer ACK Message . . . . . . . . . . . . . . . . . . . . 31
14. Peer Update Message . . . . . . . . . . . . . . . . . . . . . 32
15. Peer Update ACK Message . . . . . . . . . . . . . . . . . . . 33
16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 33
17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 33
18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 34
19. Neighbor Up ACK Message . . . . . . . . . . . . . . . . . . . 35
20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 35
21. Neighbor Down ACK Message . . . . . . . . . . . . . . . . . . 35
22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 36
23. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 36
24. Link Characteristics Request Message . . . . . . . . . . . . . 37
25. Link Characteristics ACK Message . . . . . . . . . . . . . . . 37
26. Security Considerations . . . . . . . . . . . . . . . . . . . 38
27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
27.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 38
27.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 39
27.3 Signal (Message) TLV Type Registration . . . . . . . . . . 39
27.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 39
27.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 40
27.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 40
30. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 40
30.1 Peer Level Message Flows . . . . . . . . . . . . . . . . . 40
30.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 40
30.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 41
30.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 42
30.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 42
30.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 43
30.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 43
30.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 44
30.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 44
30.2 Neighbor Specific Message Flows . . . . . . . . . . . . . 44
30.2.1 Modem Neighbor Up Lost . . . . . . . . . . . . . . . . 45
30.2.2 Router Detects Duplicate Neighbor Ups . . . . . . . . 45
30.2.3 Neighbor Up, No Layer 3 Addresses . . . . . . . . . . 46
30.2.4 Neighbor Up with IPv4, No IPv6 . . . . . . . . . . . . 46
30.2.5 Neighbor Up with IPv4 and IPv6 . . . . . . . . . . . . 46
30.2.6 Neighbor Session Success . . . . . . . . . . . . . . . 47
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . . . . 47
Informative References . . . . . . . . . . . . . . . . . . . . . . 48
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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 bandwidth and quality. Examples of these types of links variable bandwidth and quality. Examples of these types of links
include line-of-sight (LOS) radios, satellite terminals, and include line-of-sight (LOS) radios, satellite terminals, and
cable/DSL modems. Fluctuations in speed and quality of these links cable/DSL modems. Fluctuations in speed and quality of these links
can occur due to configuration (in the case of cable/DSL modems), or can occur due to configuration (in the case of cable/DSL modems), or
on a moment-to-moment basis, due to physical phenomena like multipath on a moment-to-moment basis, due to physical phenomena like multipath
interference, obstructions, rain fade, etc. It is also quite possible interference, obstructions, rain fade, etc. It is also quite possible
that link quality and bandwidth varies with respect to individual that link quality and bandwidth varies with respect to individual
neighbors on a link, and with the type of traffic being sent. As an neighbors on a link, and with the type of traffic being sent. As an
example, consider the case of an 802.11g access point, serving 2 example, consider the case of an 802.11g access point, serving 2
skipping to change at page 7, line 39 skipping to change at page 7, line 46
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 utilize a discovery technique to locate
each other, thus avoiding a-priori configuration. Either entity (the each other, thus avoiding a-priori configuration. The modem is
router or the modem) can initiate the discovery process. In cases responsible for initialing the discovery process, using the Peer
where both entities initiate discovery, a race condition can occur. Discovery message.
When this race condition occurs, the router MUST cease its active
discovery, and respond to the modem's request.
DLEP utilizes a session-oriented paradigm. A router and modem form a DLEP utilizes a session-oriented paradigm. A router and modem form a
session by completing the discovery process. This router-modem session by completing the discovery process. This router-modem
session persists unless or until it either (1) times out, based on session persists unless or until it either (1) times out, based on
the timeout values supplied, or (2) is explicitly torn down by one of the timeout values supplied, or (2) is explicitly torn down by one of
the participants. Note that use of timers in DLEP is OPTIONAL; that the participants. Note that use of timers in DLEP is OPTIONAL; that
is, implementations can choose to run with no timers (or effectively, is, implementations can choose to run with no timers (or effectively,
timers set to an infinite value). timers set to an infinite value).
DLEP assumes that participating modems, and their physical links, act DLEP assumes that participating modems, and their physical links, act
skipping to change at page 9, line 37 skipping to change at page 9, line 43
the variable-quality link in use. As mentioned in the introduction the variable-quality link in use. As mentioned in the introduction
section of this document, metrics have to be used within a context - section of this document, metrics have to be used within a context -
for example, metrics to a unicast address in the network. DLEP allows for example, metrics to a unicast address in the network. DLEP allows
for metrics to be sent within two contexts - metrics for a specific for metrics to be sent within two contexts - metrics for a specific
neighbor (those for a given destination within the network), and neighbor (those for a given destination within the network), and
"modem-wide" (those that apply to all destinations accessed via the "modem-wide" (those that apply to all destinations accessed via the
modem). Metrics supplied on DLEP Peer signals are, by definition, modem). Metrics supplied on DLEP Peer signals are, by definition,
modem-wide; metrics supplied on Neighbor signals are, by definition, modem-wide; metrics supplied on Neighbor signals are, by definition,
used for the specific neighbor only. used for the specific neighbor only.
Metrics are further subdivided into transmit and receive metrics.
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. Additionally, this mechanism on their specific characteristics. Additionally, this mechanism
(either at a modem-wide or specific neighbor context) MAY be used to (either at a modem-wide or specific neighbor context) MAY be used to
report non-changing, or static, metrics. Modems having static link report non-changing, or static, metrics. Modems having static link
metric characteristics MAY report metrics only once for a given metric characteristics MAY report metrics only once for a given
neighbor (or once on a modem-wide basis, if all connections via the neighbor (or once on a modem-wide basis, if all connections via the
modem are of this static nature). 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
skipping to change at page 10, line 37 skipping to change at page 10, line 44
associated data items, could be used to implement new flow control associated data items, could be used to implement new flow control
schemes. If subsequent research and development define new features schemes. If subsequent research and development define new features
and function, then it should be standardized either as an update to and function, then it should be standardized either as an update to
this document, or as an additional stand-alone specification. this document, or as an additional stand-alone specification.
6. Normal Session Flow 6. Normal Session Flow
At the start of a run, DLEP implementations (both router and modem) At the start of a run, DLEP implementations (both router and modem)
initialize the communications path. In a UDP implementation, this initialize the communications path. In a UDP implementation, this
includes opening a socket and binding to the well-known port address includes opening a socket and binding to the well-known port address
(TBD). Once the communications path is established, an implementation (TBD). Once the communications path is established, modem
would either, depending on configuration, proceed to periodically implementations are free to issue a "Peer Discovery" message. The
issue a "Peer Discovery" message. The Peer Discovery MAY be sent Peer Discovery MAY be sent either to the multicast address allocated
either via the multicast address allocated for DLEP (TBD), or via a for DLEP (TBD), or to a unicast address, obtained via a-priori
unicast address, or drop into a "passive receive" mode, waiting on configuration.
receipt of a Peer Discovery.
Both modem and router initialize in a "discovery" state. Either the
modem, the router, or both, will then issue a "Peer Discovery"
signal. The Peer Discovery signal MAY be issued to a unicast address
(if a-priori knowledge of the address exists), or to the multicast
address TBD.
The receiver of a Peer Discovery message responds with a "Peer Offer" Routers receiving a Peer Discovery message respond with a "Peer
signal to indicate readiness to participate in the DLEP session. The Offer" signal to indicate readiness to participate in the DLEP
receiver of a Peer Offer message responds with a "Peer Offer ACK" session. The receiver of a Peer Offer message responds with a "Peer
message, completing discovery. While the Peer Discovery message MAY Offer ACK" message, completing discovery. While the Peer Discovery
be sent to the DLEP multicast address (TBD), the Peer Offer, and all message MAY be sent to the DLEP multicast address (TBD), the Peer
subsequent traffic, is sent to the unicast address that originated Offer, and all subsequent traffic, is sent to the unicast address
the Peer Discovery. Once the Peer Offer signal is acknowledged, both that originated the Peer Discovery. Once the Peer Offer signal is
participants (router and modem) transition to the "in session" state, acknowledged, both participants (router and modem) transition to the
creating a logical, stateful session between the modem and the "in session" state, creating a logical, stateful session between the
router. Subsequent DLEP signals are then processed within the context modem and the router. Subsequent DLEP signals are then processed
of this router/modem session. DLEP partners use these signals to within the context of this router/modem session. In the UDP-based
build their respective information bases regarding destinations that implementation, traffic between DLEP modems and routers is correlated
are accessible via the modem, and link characteristics associated using the UDP 4-tuple (Source Address, Source Port, Destination
with those destinations. Address, Destination Port). DLEP partners use these signals to build
their respective information bases regarding destinations that are
accessible via the modem, and link characteristics associated with
those destinations.
The "in session" state created by the discovery signals is maintained The "in session" state created by the discovery signals is maintained
until one of the following conditions occur: until one of the following conditions occur:
o The session is explicitly terminated (using Peer Termination), or o The session is explicitly terminated (using Peer Termination), or
o The session times out, based on supplied timeout values. o The session times out, based on supplied timeout values.
In order to maintain the session between router and modem, OPTIONAL In order to maintain the session between router and modem, OPTIONAL
periodic "Heartbeat" messages MAY be exchanged. These messages are periodic "Heartbeat" messages MAY be exchanged. These messages are
intended to keep the session alive, and to verify bidirectional intended to keep the session alive, and to verify bidirectional
skipping to change at page 12, line 27 skipping to change at page 12, line 31
manner. manner.
7. Mandatory Signals and Data Items 7. Mandatory Signals and Data Items
The following DLEP signals are considered core to the specification; The following DLEP signals are considered core to the specification;
implementations MUST support these signals, and the associated data implementations MUST support these signals, and the associated data
items, in order to be considered compliant: items, in order to be considered compliant:
Signal Data Items Signal Data Items
====== ========== ====== ==========
Attached Peer Discovery Identification Peer Discovery None
Peer Offer Identification Peer Offer None
Peer Offer ACK Status Peer Offer ACK Status
Peer Termination Identification Peer Termination None
Peer Termination ACK Status Peer Termination ACK Status
Neighbor Up Identification Neighbor Up MAC Address
MAC Address
Maximum Data Rate Maximum Data Rate
Current Data Rate Current Data Rate
Latency
Resources
Relative Link Quality
Neighbor Update Identification Neighbor Update MAC Address
MAC Address
Maximum Data Rate Maximum Data Rate
Current Data Rate Current Data Rate
Latency
Resources
Relative Link Quality
Neighbor Down Identification Neighbor Down MAC Address
MAC Address
All other DLEP signals and data items are OPTIONAL. Implementations All other DLEP signals and data items are OPTIONAL. Implementations
MAY choose to provide them. Implementations that do not support MAY choose to provide them. Implementations that do not support
optional signals and data items SHOULD parse, and silently drop, all optional signals and data items SHOULD parse, and silently drop, all
unsupported signals and/or data items. unsupported signals and/or data items.
8. Generic DLEP Packet Definition 8. Generic DLEP Packet Definition
The Generic DLEP Packet consists of a sequence of TLVs. The first TLV The Generic DLEP Packet consists of a sequence of TLVs. The first TLV
represents the signal being communicated (e.g., a "Neighbor Up", or a represents the signal being communicated (e.g., a "Neighbor Up", or a
skipping to change at page 14, line 4 skipping to change at page 13, line 45
one of the Signal TLVs, documented in section [INSERT REFERENCE one of the Signal TLVs, documented in section [INSERT REFERENCE
HERE]. The signals are followed by one or more data items, indicating HERE]. The signals are followed by one or more data items, indicating
the specific changes that need to be instantiated in the receiver's the specific changes that need to be instantiated in the receiver's
information base. information base.
Valid DLEP Data Items are: Valid DLEP Data Items are:
TLV TLV TLV TLV
Value Description Value Description
========================================= =========================================
TBD Identification
TBD DLEP Version TBD DLEP Version
TBD Peer Type TBD Peer Type
TBD IPv4 Address TBD IPv4 Address
TBD IPv6 Address TBD IPv6 Address
TBD Maximum Data Rate (MDR) TBD Maximum Data Rate (Receive) (MDRR)
TBD Current Data Rate (CDR) TBD Maximum Data Rate (Transmit) (MDRT)
TBD Latency TBD Current Data Rate (Receive) (CDRR)
TBD Resources TBD Current Data Rate (Transmit) (CDRT)
TBD Transmit Latency
TBD Receive Resources
TBD Transmit Resources
TBD Expected Forwarding Time (EFT) TBD Expected Forwarding Time (EFT)
TBD Relative Link Quality (RLQ) TBD Relative Link Quality (Receive) (RLQR)
TBD Relative Link Quality (Transmit) (RLQT)
TBD Status TBD Status
TBD Heartbeat Interval/Threshold TBD Heartbeat Interval/Threshold
TBD Neighbor down ACK timer TBD Neighbor down ACK timer
TBD Link Characteristics ACK timer TBD Link Characteristics ACK timer
TBD Credit Window Status TBD Credit Window Status
TBD Credit Grant TBD Credit Grant
TBD Credit Request TBD Credit Request
DLEP data item TLVs contain the following fields: DLEP data item TLVs contain the following fields:
skipping to change at page 14, line 39 skipping to change at page 14, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - An 8-bit unsigned integer field specifying the data TLV Type - An 8-bit unsigned integer field specifying the data
item being sent. item being sent.
Length - An 8-bit length of the value field of the data item Length - An 8-bit length of the value field of the data item
Value - A field of length <Length> which contains data Value - A field of length <Length> which contains data
specific to a particular data item. specific to a particular data item.
9.1 Identification 9.1 DLEP Version
This data item MUST exist in all DLEP messages, and MUST be the first
data item of the message (e.g., it MUST immediately follow the signal
TLV). Further, there MUST be ONLY one Identification data item in a
DLEP message. The data item contains identification information used
to establish the proper context (e.g., the router/modem session) for
processing DLEP protocol messages.
The format of the Identification Data Item is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = TBD | Length = 8 | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID | Modem ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modem ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - Value TBD
Length - 8
Router ID - Indicates the Router ID of the DLEP session.
Modem ID - indicates the Modem ID of the DLEP session.
During transmission of a DLEP Peer Discovery signal, the transmitter
MUST set its ID to a 32-bit quantity that will be used to uniquely
identify this session from the transmitter's perspective. The other
ID value MUST be set the to '0'. When responding to the Peer
Discovery signal (via the Peer Offer signal), the transmitter MUST
echo any received ID value, and MUST supply its own unique 32-bit
quantity to identify the session from its perspective. After the Peer
Discovery/Peer Offer exchange, subsequent signals on this DLEP
session MUST contain the ID values obtained from the Peer
Discovery/Peer Offer sequence.
9.2 DLEP Version
The DLEP Version TLV is an OPTIONAL TLV in both the Peer Discovery The DLEP Version TLV is an OPTIONAL TLV in both the Peer Discovery
and Peer Offer messages. The Version TLV is used to indicate the and Peer Offer messages. The Version TLV is used to indicate the
version of the protocol running in the originator. A participant MAY version of the protocol running in the originator. A participant MAY
use this information to decide if the potential session partner is use this information to decide if the potential session partner is
running at a supported level. running at a supported level.
The DLEP Version TLV contains the following fields: The DLEP Version TLV contains the following fields:
0 1 2 3 0 1 2 3
skipping to change at page 16, line 4 skipping to change at page 15, line 9
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length=4 | Major Version | |TLV Type =TBD |Length=4 | Major Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version | | Minor Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - Length is 4 Length - Length is 4
Major Version - Major version of the modem or router protocol. Major Version - Major version of the modem or router protocol.
Minor Version - Minor version of the modem or router protocol. Minor Version - Minor version of the modem or router protocol.
Support of this draft is indicated by setting the Major Version Support of this draft is indicated by setting the Major Version
to '1', and the Minor Version to '3' (e.g. Version 1.3). to '1', and the Minor Version to '3' (e.g. Version 1.3).
9.3 Peer Type 9.2 Peer Type
The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and
Peer Offer messages. The Peer Type TLV is used by the router and Peer Offer messages. The Peer Type TLV is used by the router and
modem to give additional information as to its type. The peer type is modem to give additional information as to its type. The peer type is
a string and is envisioned to be used for informational purposes a string and is envisioned to be used for informational purposes
(e.g. as output in a display command). (e.g. as output in a display command).
The Peer Type TLV contains the following fields: The Peer Type TLV contains the following fields:
0 1 2 3 0 1 2 3
skipping to change at page 16, line 38 skipping to change at page 15, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - Length of peer type string (80 octets maximum). Length - Length of peer type string (80 octets maximum).
Peer Type String - Non-Null terminated string, maximum length of 80 Peer Type String - Non-Null terminated string, maximum length of 80
octets. For example, a satellite modem might set octets. For example, a satellite modem might set
this variable to 'Satellite terminal'. this variable to 'Satellite terminal'.
9.4 MAC Address 9.3 MAC Address
The MAC address TLV MUST appear in all neighbor-oriented signals The MAC address TLV MUST appear in all neighbor-oriented signals
(e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK, (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK,
Neighbor Update, Link Characteristics Request, and Link Neighbor Update, Link Characteristics Request, and Link
Characteristics ACK). The MAC Address TLV contains the address of the Characteristics ACK). The MAC Address TLV contains the address of the
destination on the remote node. The MAC address MAY be either a destination on the remote node. The MAC address MAY be either a
physical or a virtual destination. Examples of a virtual destination physical or a virtual destination. Examples of a virtual destination
would be a multicast MAC address, or the broadcast MAC would be a multicast MAC address, or the broadcast MAC
(0xFFFFFFFFFFFF). (0xFFFFFFFFFFFF).
skipping to change at page 17, line 4 skipping to change at page 16, line 10
(e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK, (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK,
Neighbor Update, Link Characteristics Request, and Link Neighbor Update, Link Characteristics Request, and Link
Characteristics ACK). The MAC Address TLV contains the address of the Characteristics ACK). The MAC Address TLV contains the address of the
destination on the remote node. The MAC address MAY be either a destination on the remote node. The MAC address MAY be either a
physical or a virtual destination. Examples of a virtual destination physical or a virtual destination. Examples of a virtual destination
would be a multicast MAC address, or the broadcast MAC would be a multicast MAC address, or the broadcast MAC
(0xFFFFFFFFFFFF). (0xFFFFFFFFFFFF).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 6 | MAC Address | |TLV Type =TBD |Length = 6 | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 6 Length - 6
MAC Address - MAC Address of the destination (either physical or MAC Address - MAC Address of the destination (either physical or
virtual). virtual).
9.5 IPv4 Address 9.4 IPv4 Address
The IPv4 Address TLV is an OPTIONAL TLV. If supported, it MAY appear The IPv4 Address TLV is an OPTIONAL TLV. If supported, it MAY appear
in Neighbor Up, Neighbor Update, and Peer Update messages. When in Neighbor Up, Neighbor Update, and Peer Update messages. When
included in Neighbor messages, the IPv4 Address TLV contains the IPv4 included in Neighbor messages, the IPv4 Address TLV contains the IPv4
address of the neighbor, as well as a subnet mask value. In the Peer address of the neighbor, as well as a subnet mask value. In the Peer
Update message, it contains the IPv4 address of the originator of the Update message, it contains the IPv4 address of the originator of the
message. In either case, the TLV also contains an indication of message. In either case, the TLV also contains an indication of
whether this is a new or existing address, or is a deletion of a whether this is a new or existing address, or is a deletion of a
previously known address. previously known address.
skipping to change at page 18, line 5 skipping to change at page 17, line 10
Length - 6 Length - 6
Add/Drop - Value indicating whether this is a new or existing Add/Drop - Value indicating whether this is a new or existing
IPv4 address IPv4 address
IPv4 Address - The IPv4 address of the neighbor or peer. IPv4 Address - The IPv4 address of the neighbor or peer.
Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4
address. address.
9.6 IPv6 Address 9.5 IPv6 Address
The IPv6 Address TLV is an OPTIONAL TLV. If supported, it MAY be used The IPv6 Address TLV is an OPTIONAL TLV. If supported, it MAY be used
in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update
Messages. When included in Neighbor messages, this data item contains Messages. When included in Neighbor messages, this data item contains
the IPv6 address of the neighbor. In the Peer Discovery and Peer the IPv6 address of the neighbor. In the Peer Discovery and Peer
Update, it contains the IPv6 address of the originating peer. In Update, it contains the IPv6 address of the originating peer. In
either case, the data item also contains an indication of whether either case, the data item also contains an indication of whether
this is a new or existing address, or is a deletion of a previously this is a new or existing address, or is a deletion of a previously
known address, as well as a subnet mask. known address, as well as a subnet mask.
skipping to change at page 18, line 45 skipping to change at page 17, line 50
Length - 18 Length - 18
Add/Drop - Value indicating whether this is a new or existing Add/Drop - Value indicating whether this is a new or existing
address (0x01), or a withdrawal of an address (0x02). address (0x01), or a withdrawal of an address (0x02).
IPv6 Address - IPv6 Address of the neighbor or peer. IPv6 Address - IPv6 Address of the neighbor or peer.
Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6 Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6
address. address.
9.7 Maximum Data Rate 9.6 Maximum Data Rate (Receive)
The Maximum Data Rate Receive (MDRR) TLV is used in Neighbor Up,
Neighbor Update, Peer Discovery, Peer Update, and Link
Characteristics ACK Messages to indicate the maximum theoretical data
rate, in bits per second, that can be achieved while receiving data
on the link. When metrics are reported via the messages listed above,
the maximum data rate receive MUST be reported. A value of 0 for the
MDRR indicates that the Maximum Data Rate Receive is currently
'unknown'.
The Maximum Data Rate (MDR) TLV is used in Neighbor Up, Neighbor 0 1 2 3
Update, Peer Discovery, Peer Update, and Link Characteristics ACK 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
Messages to indicate the maximum theoretical data rate, in bits per +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
second, that can be achieved on the link. When metrics are reported |TLV Type =TBD |Length = 8 | MDRR (bps) |
via the messages listed above, the maximum data rate MUST be +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reported. | MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD
Length - 8
Maximum Data Rate Receive - A 64-bit unsigned number, representing
the maximum theoretical data rate, in bits per
second (bps), that can be achieved while
receiving on the link. An MDRR value of 0 MAY be
used to indicate an 'unknown' data rate.
9.7 Maximum Data Rate (Transmit)
The Maximum Data Rate Transmit (MDRT) TLV is used in Neighbor Up,
Neighbor Update, Peer Discovery, Peer Update, and Link
Characteristics ACK Messages to indicate the maximum theoretical data
rate, in bits per second, that can be achieved while transmitting
data on the link. When metrics are reported via the messages listed
above, the maximum data rate transmit MUST be reported. A value of 0
for the MDRT MAY be used to indicate that the Maximum Data Rate
Transmit is currently unknown, or cannot be calculated.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 8 | MDR (bps) | |TLV Type =TBD |Length = 8 | MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDR (bps) | | MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDR (bps) | | MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 8 Length - 8
Maximum Data Rate - A 64-bit unsigned number, representing the Maximum Data Rate Transmit - A 64-bit unsigned number, representing
maximum theoretical data rate, in bits per the maximum theoretical data rate, in bits per
second (bps), that can be achieved on the link. second (bps), that can be achieved while
transmitting on the link. An MDRT value of 0
indicates an 'unknown' data rate.
9.8 Current Data Rate 9.8 Current Data Rate (Receive)
The Current Data Rate (CDR) TLV is used in Neighbor Up, Neighbor The Current Data Rate Receive (CDRR) TLV is used in Neighbor Up,
Update, Peer Discovery, Peer Update, Link Characteristics Request, Neighbor Update, Peer Discovery, Peer Update, Link Characteristics
and Link Characteristics ACK messages to indicate the rate at which Request, and Link Characteristics ACK messages to indicate the rate
the link is currently operating, or in the case of the Link at which the link is currently operating for receiving traffic. In
Characteristics Request, the desired data rate for the link. When the case of the Link Characteristics Request, CDRR represents the
metrics are reported via the messages above, the current data rate desired receive data rate for the link. When metrics are reported via
MUST be reported. the messages above (e.g. Neighbor Update), the current data rate
receive MUST be reported.
The Current Data Rate TLV contains the following fields: The Current Data Rate Receive TLV contains the following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDR (bps) | |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDR (bps) | | CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDR (bps) | | CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 8 Length - 8
Current Data Rate - A 64-bit unsigned number, representing the Current Data Rate Receive - A 64-bit unsigned number, representing
current data rate, in bits per second, that is the current data rate, in bits per second, that
currently be achieved on the link, or the is currently be achieved while receiving traffic
desired data rate in bits per second in the Link on the link. When used in the Link
Characteristics Request message. If there is no Characteristics Request, CDRR represents the
distinction between current and maximum data desired receive rate, in bits per second, on the
rates, current data rate MUST be set equal to link. If there is no distinction between current
the maximum data rate. and maximum receive data rates, current data
rate receive SHOULD be set equal to the maximum
data rate receive. A CDRR value of 0 MAY be used
to indicate the CDRT is unknown, or cannot be
calculated.
9.9 Expected Forwarding Time 9.9 Current Data Rate (Transmit)
The Current Data Rate Receive (CDRT) TLV is used in Neighbor Up,
Neighbor Update, Peer Discovery, Peer Update, Link Characteristics
Request, and Link Characteristics ACK messages to indicate the rate
at which the link is currently operating for transmitting traffic. In
the case of the Link Characteristics Request, CDRT represents the
desired transmit data rate for the link. When metrics are reported
via the messages above (e.g. Neighbor Update), the current data rate
transmit MUST be reported.
The Current Data Rate Transmit TLV contains the following fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD
Length - 8
Current Data Rate Transmit - A 64-bit unsigned number, representing
the current data rate, in bits per second, that
is currently be achieved while transmitting
traffic on the link. When used in the Link
Characteristics Request, CDRT represents the
desired transmit rate, in bits per second, on
the link. If there is no distinction between
current and maximum transmit data rates, current
data rate transmit MUST be set equal to the
maximum data rate transmit. A CDRT value of 0
MAY be used to indicate the CDRT is 'unknown',
or cannot be calculated.
9.10 Expected Forwarding Time
The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item. The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item.
If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer
Discovery, and Peer Update messages to indicate the typical latency Discovery, and Peer Update messages to indicate the typical latency
between the arrival of a given packet at the transmitting device and between the arrival of a given packet at the transmitting device and
the reception of the packet at the other end of the link. EFT the reception of the packet at the other end of the link. EFT
combines transmission time, idle time, waiting time, freezing time, combines transmission time, idle time, waiting time, freezing time,
and queuing time to the degree that those values are meaningful to a and queuing time to the degree that those values are meaningful to a
given transmission medium. given transmission medium.
skipping to change at page 20, line 40 skipping to change at page 21, line 33
| EFT (ms) | | EFT (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 4 Length - 4
EFT - A 32-bit unsigned number, representing the expected EFT - A 32-bit unsigned number, representing the expected
forwarding time, in milliseconds, on the link. forwarding time, in milliseconds, on the link.
9.10 Latency 9.11 Latency
The Latency TLV is used in Neighbor Up, Neighbor Update, Peer The Latency TLV is an OPTIONAL data item. If supported, it is used in
Discovery, Peer Update, Link Characteristics Request, and Link Neighbor Up, Neighbor Update, Peer Discovery, Peer Update, Link
Characteristics ACK messages to indicate the amount of latency on the Characteristics Request, and Link Characteristics ACK messages to
link, or in the case of the Link Characteristics Request, to indicate indicate the amount of latency on the link, or in the case of the
the maximum latency required on the link. When metrics are reported Link Characteristics Request, to indicate the maximum latency
via the messages above, Latency MUST be reported. required on the link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 2 | Latency (ms) | |TLV Type =TBD |Length = 2 | Latency (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 2 Length - 2
skipping to change at page 21, line 12 skipping to change at page 22, line 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 2 | Latency (ms) | |TLV Type =TBD |Length = 2 | Latency (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 2 Length - 2
Latency - A 16-bit unsigned value, representing the transmission Latency - A 16-bit unsigned value, representing the transmission
delay that a packet encounters as it is transmitted delay that a packet encounters as it is transmitted
over the link. In Neighbor Up, Neighbor Update, and over the link. In Neighbor Up, Neighbor Update, and
Link Characteristics ACK, this value is reported as Link Characteristics ACK, this value is reported as
delay, in milliseconds. The calculation of latency is delay, in milliseconds. The calculation of latency is
implementation dependent. For example, the latency may implementation dependent. For example, the latency may
be a running average calculated from the internal be a running average calculated from the internal
queuing. If a device cannot calculate latency, it MUST queuing. If a device cannot calculate latency, this
be reported as 0. In the Link Characteristics Request TLV SHOUD NOT be issued. In the Link Characteristics
Message, this value represents the maximum delay, in Request Message, this value represents the maximum
milliseconds, expected on the link. delay, in milliseconds, expected on the link.
9.11 Resources 9.12 Resources (Receive)
The Resources TLV is used in Neighbor Up, Neighbor Update, Peer The Receive Resources TLV is an OPTIONAL data item. If supported, it
Discovery, Peer Update, and Link Characteristics ACK messages to is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update,
indicate a percentage (0-100) amount of resources (e.g. battery and Link Characteristics ACK messages to indicate a percentage (0-
power) remaining on the originating peer. If metrics are reported, 100) amount of resources (e.g. battery power), committed to receiving
via the above messages, Resources MUST be reported. data, remaining on the originating peer.
The Resources TLV contains the following fields: The Resources TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 | Resources | |TLV Type =TBD |Length = 1 | Rcv Resources|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 1 Length - 1
Resources - A percentage, 0-100, representing the amount of Receive Resources - A percentage, 0-100, representing the amount
remaining resources, such as battery power. If of remaining resources, such as battery power,
resources cannot be calculated, a value of 100 MUST be allocated to receiving data. A value of '0' MAY be
reported. used to indicate the receive resources are unknown or
cannot be calculated.
9.12 Relative Link Quality 9.13 Resources (Transmit)
The Relative Link Quality (RLQ) TLV is used in Neighbor Up, Neighbor The Transmit Resources TLV is an OPTIONAL data item. If supported, it
Update, Peer Discovery, Peer Update, and Link Characteristics ACK is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update,
messages to indicate the quality of the link as calculated by the and Link Characteristics ACK messages to indicate a percentage (0-
originating peer. If metrics are reported via the above messages, RLQ 100) amount of resources (e.g. battery power), committed to
MUST be reported. transmitting data, remaining on the originating peer.
The Relative Link Quality TLV contains the following fields: The Resources TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 |Relative Link | |TLV Type =TBD |Length = 1 | Xmt Resources|
| | |Quality (RLQ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD
Length - 1
Transmit Resources - A percentage, 0-100, representing the amount
of remaining resources, such as battery power,
allocated to transmitting data. A value of '0' MAY be
used to indicate the transmit resources are unknown or
cannot be calculated.
9.14 Relative Link Quality (Receive)
The Relative Link Quality Receive (RLQR) TLV is an OPTIONAL data
item. If supported, it is used in Neighbor Up, Neighbor Update, Peer
Discovery, Peer Update, and Link Characteristics ACK messages to
indicate the quality of the link for receiving data as calculated by
the originating peer.
The Relative Link Quality (Receive) TLV contains the following
fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 |RCV Rel. Link |
| | |Quality (RLQR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 1 Length - 1
Relative Link Quality - A non-dimensional number, 0-100, Relative Link Quality (Receive) - A non-dimensional number, 1-100,
representing relative link quality. A value of representing relative link quality. A value of
100 represents a link of the highest quality. 100 represents a link of the highest quality.
If the RLQ cannot be calculated, a value of A value of '0' indicated the RLQR is
100 MUST be reported. 'unknown', or cannot be calculated.
9.13 Status 9.15 Relative Link Quality (Transmit)
The Status TLV is an OPTIONAL TLV. It is sent as part of an The Transmit Link Quality Receive (RLQT) TLV is an OPTIONAL data
acknowledgement message, from either the modem or the router, to item. If supported, it is used in Neighbor Up, Neighbor Update, Peer
indicate the success or failure of a given request. Discovery, Peer Update, and Link Characteristics ACK messages to
indicate the quality of the link for transmitting data as calculated
by the originating peer.
The Relative Link Quality (Transmit) TLV contains the following
fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 |XMT Rel. Link |
| | |Quality (RLQR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD
Length - 1
Relative Link Quality (Transmit) - A non-dimensional number, 1-100,
representing relative link quality. A value of
100 represents a link of the highest quality.
A value of '0' indicated the RLQT is
'unknown', or cannot be calculated.
9.16 Status
The Status TLV is sent as part of an acknowledgement message, from
either the modem or the router, to indicate the success or failure of
a given request.
The Status TLV contains the following fields: The Status TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 | Code | |TLV Type =TBD |Length = 1 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD TLV Type - TBD
Length - 1 Length - 1
Termination Code - 0 = Success, Non-zero = Failure. Specific values Termination Code - 0 = Success, Non-zero = Failure. Specific values
of a non-zero termination code depend on the of a non-zero termination code depend on the
operation requested (e.g. Neighbor Up, operation requested (e.g. Neighbor Up,
Neighbor Down, etc). Neighbor Down, etc).
9.14 Heartbeat Interval/Threshold 9.17 Heartbeat Interval/Threshold
The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. If The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. If
supported, it MAY be sent during Peer Discovery to indicate the supported, it MAY be sent during Peer Discovery to indicate the
desired Heartbeat timeout window. If the modem includes the Heartbeat desired Heartbeat timeout window. If the modem includes the Heartbeat
Interval TLV in Peer Discovery, the router MUST either accept the Interval TLV in Peer Discovery, the router MUST either accept the
timeout interval supplied by the modem, or reject the Peer Discovery. timeout interval supplied by the modem, or reject the Peer Discovery.
Peer Discovery messages that do not include the Heartbeat Interval Peer Discovery messages that do not include the Heartbeat Interval
TLV in Peer Discovery indicates a desire to establish the TLV in Peer Discovery indicates a desire to establish the
router/modem session without an activity timeout (e.g. an infinite router/modem session without an activity timeout (e.g. an infinite
timeout value). If an activity timeout is supported, implementations timeout value). If an activity timeout is supported, implementations
skipping to change at page 24, line 5 skipping to change at page 26, line 6
Length - 1 Length - 1
Interval - 0 = Do NOT use heartbeats on this peer-to-peer Interval - 0 = Do NOT use heartbeats on this peer-to-peer
session. Non-zero = Interval, in seconds, for session. Non-zero = Interval, in seconds, for
heartbeat messages. heartbeat messages.
Threshold - Number of windows, of Heartbeat Interval seconds, Threshold - Number of windows, of Heartbeat Interval seconds,
to wait before declaring a peer-to-peer session to to wait before declaring a peer-to-peer session to
be lost. be lost.
9.15 Link Characteristics ACK Timer 9.18 Link Characteristics ACK Timer
The Link Characteristics ACK Timer TLV is an OPTIONAL TLV. If The Link Characteristics ACK Timer TLV is an OPTIONAL TLV. If
supported, it MAY be sent during Peer Discovery to indicate the supported, it MAY be sent during Peer Discovery to indicate the
desired number of seconds to wait for a response to a Link desired number of seconds to wait for a response to a Link
Characteristics Request. If a router receives this TLV from a modem Characteristics Request. If a router receives this TLV from a modem
during Peer Discovery, the router MUST either accept the timeout during Peer Discovery, the router MUST either accept the timeout
value, or reject the Peer Discovery. If this TLV is omitted, value, or reject the Peer Discovery. If this TLV is omitted,
implementations supporting the Link Characteristics Request SHOULD implementations supporting the Link Characteristics Request SHOULD
choose a default value. choose a default value.
skipping to change at page 24, line 33 skipping to change at page 26, line 34
TLV Type - TBD TLV Type - TBD
Length - 1 Length - 1
Interval - 0 = Do NOT use timeouts for Link Characteristics Interval - 0 = Do NOT use timeouts for Link Characteristics
requests on this router/modem session. Non-zero = requests on this router/modem session. Non-zero =
Interval, in seconds, to wait before considering a Interval, in seconds, to wait before considering a
Link Characteristics Request has been lost. Link Characteristics Request has been lost.
9.16 Credit Window Status 9.19 Credit Window Status
The Credit Window Status TLV is an OPTIONAL TLV. If credits are The Credit Window Status TLV is an OPTIONAL TLV. If credits are
supported by the DLEP participants (both the router and the modem), supported by the DLEP participants (both the router and the modem),
the Credit Window Status TLV MUST be sent by the participant the Credit Window Status TLV MUST be sent by the participant
receiving a Credit Grant Request for a given neighbor. receiving a Credit Grant Request for a given neighbor.
The Credit Window Status TLV contains the following fields: The Credit Window Status TLV contains the following fields:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 25, line 21 skipping to change at page 27, line 24
Modem Receive Window Value - A 64-bit unsigned number, indicating Modem Receive Window Value - A 64-bit unsigned number, indicating
the current (or initial) number of the current (or initial) number of
credits available on the Modem Receive credits available on the Modem Receive
Window. Window.
Router Receive Window Value - A 64-bit unsigned number, indicating Router Receive Window Value - A 64-bit unsigned number, indicating
the current (or initial) number of the current (or initial) number of
credits available on the Router Receive credits available on the Router Receive
Window. Window.
9.17 Credit Grant Request 9.20 Credit Grant Request
The Credit Grant Request TLV is an OPTIONAL TLV. If credits are The Credit Grant Request TLV is an OPTIONAL TLV. If credits are
supported, the Credit Grant Request TLV is sent from a DLEP supported, the Credit Grant Request TLV is sent from a DLEP
participant to grant an increment to credits on a window. The Credit participant to grant an increment to credits on a window. The Credit
Grant TLV is sent as a data item in either the Neighbor Up or Grant TLV is sent as a data item in either the Neighbor Up or
Neighbor Update messages. The value in a Credit Grant TLV represents Neighbor Update messages. The value in a Credit Grant TLV represents
an increment to be added to any existing credits available on the an increment to be added to any existing credits available on the
window. Upon successful receipt and processing of a Credit Grant TLV, window. Upon successful receipt and processing of a Credit Grant TLV,
the receiver MUST respond with a message containing a Credit Window the receiver MUST respond with a message containing a Credit Window
Status TLV to report the updated aggregate values for synchronization Status TLV to report the updated aggregate values for synchronization
skipping to change at page 26, line 26 skipping to change at page 28, line 30
additional credits to be assigned to the credit additional credits to be assigned to the credit
window. Since credits can only be granted by the window. Since credits can only be granted by the
receiver on a window, the applicable credit window receiver on a window, the applicable credit window
(either the MRW or the RRW) is derived from the (either the MRW or the RRW) is derived from the
sender of the grant. The Credit Increment MUST NOT sender of the grant. The Credit Increment MUST NOT
cause the window to overflow; if this condition cause the window to overflow; if this condition
occurs, implementations MUST set the credit window occurs, implementations MUST set the credit window
to the maximum value contained in a 64-bit to the maximum value contained in a 64-bit
quantity. quantity.
9.18 Credit Request 9.21 Credit Request
The Credit Request TLV is an OPTIONAL TLV. If credits are supported, The Credit Request TLV is an OPTIONAL TLV. If credits are supported,
the Credit Request TLV MAY be sent from either DLEP participant, via the Credit Request TLV MAY be sent from either DLEP participant, via
a Neighbor Update signal, to indicate the desire for the partner to a Neighbor Update signal, to indicate the desire for the partner to
grant additional credits in order for data transfer to proceed on the grant additional credits in order for data transfer to proceed on the
session. If the corresponding Neighbor Up message for this session session. If the corresponding Neighbor Up message for this session
did NOT contain a Credit Window Status TLV, indicating that credits did NOT contain a Credit Window Status TLV, indicating that credits
are to be used on the session, then the Credit Request TLV MUST be are to be used on the session, then the Credit Request TLV MUST be
rejected by the receiver via a Neighbor Update ACK message. rejected by the receiver via a Neighbor Update ACK message.
skipping to change at page 28, line 12 skipping to change at page 30, line 17
TBD Neighbor Up ACK TBD Neighbor Up ACK
TBD Neighbor Down TBD Neighbor Down
TBD Neighbor Down ACK TBD Neighbor Down ACK
TBD Neighbor Update TBD Neighbor Update
TBD Heartbeat TBD Heartbeat
TBD Link Characteristics Request TBD Link Characteristics Request
TBD Link Characteristics ACK TBD Link Characteristics ACK
11. Peer Discovery Message 11. Peer Discovery Message
The Peer Discovery Message is sent to begin a new DLEP association. The Peer Discovery Message is sent by a modem to begin a new DLEP
The Peer Offer message is required to complete the discovery process. association. The Peer Offer message is required to complete the
Implementations MAY implement their own retry heuristics in cases discovery process. Implementations MAY implement their own retry
where it is determined the Peer Discovery Message has timed out. A heuristics in cases where it is determined the Peer Discovery Message
Peer Discovery Message received from a participant that is already in has timed out. A Peer Discovery Message received from a modem that is
session MUST be processed as if a Peer Termination Message had been already in session MUST be processed as if a Peer Termination Message
received. An implementation MAY then process the received Peer had been received. A router implementation MAY then process the
Discovery Message. received Peer Discovery Message.
Note that metric data items MAY be supplied with the Peer Discovery, Note that metric data items MAY be supplied with the Peer Discovery,
in order to populate default metric values, or to indicate a static, in order to populate default metric values, or to indicate a static,
modem-wide environment. If metrics are supplied with the Peer modem-wide environment. If metrics are supplied with the Peer
Discovery message, these metrics MUST be used as the initial values Discovery message, these metrics MUST be used as the initial values
for all neighbors established via the modem. for all neighbors (remote nodes) established via the modem.
Given the packet format described in section 11, the initial TLV Type Given the packet format described in section 11, the initial TLV Type
value is set to DLEP_PEER_DISCOVERY (value TBD). Mandatory TLVs are value is set to DLEP_PEER_DISCOVERY (value TBD). OPTIONAL TLVs are
then placed into the packet: then placed into the packet:
Mandatory Data Item TLVs:
- Identification
After the Mandatory data item, implementations MAY place any OPTIONAL
TLVs they support:
Optional Data Item TLVs: Optional Data Item TLVs:
- DLEP Version - DLEP Version
- DLEP Peer Type - DLEP Peer Type
- Heartbeat Interval - Heartbeat Interval
- Heartbeat Threshold - Heartbeat Threshold
- Link Characteristics ACK Timer - Link Characteristics ACK Timer
- Maximum Data Rate - Maximum Data Rate (Receive)
- Current Data Rate - Maximum Data Rate (Transmit)
- Current Data Rate (Receive)
- Current Data Rate (Transmit)
- Latency - Latency
- Expected Forwarding Time - Expected Forwarding Time
- Resources - Resources (Receive)
- Relative Link Quality - Resources (Transmit)
- Relative Link Quality (Receive)
- Relative Link Quality (Transmit)
12. Peer Offer Message 12. Peer Offer Message
The Peer Offer Message is sent by a DLEP participant in response to a
Peer Discovery Message. Upon receipt, and successful processing, of a The Peer Offer Message is sent by a DLEP router in response to a Peer
Peer Offer message, the recipient MUST respond with a Peer Offer ACK Discovery Message. Upon receipt, and processing, of a Peer Offer
message, completing the discovery phase of DLEP. Both DLEP message, the modem MUST respond with a Peer Offer ACK message,
participants (router and modem) would then enter an "in session" completing the discovery phase of DLEP. Both DLEP participants
state. Any subsequent Discovery messages sent or received on this (router and modem) would then enter an "in session" state. Any
session MUST be considered an error, and the session MUST be subsequent Discovery messages sent or received on this session MUST
terminated as if a Peer Termination Message had been received. be considered an error, and the session MUST be terminated as if a
Peer Termination Message had been received.
The Peer Offer message MUST be sent to the unicast address of the The Peer Offer message MUST be sent to the unicast address of the
originator of Peer Discovery, regardless of whether the discovery was originator of Peer Discovery, regardless of whether the discovery was
received on the DLEP multicast address (TBD) or on a unicast received on the DLEP multicast address (TBD) or on a unicast
address. address.
To construct a Peer Offer message, the initial TLV type value is set To construct a Peer Offer message, the initial TLV type value is set
to DLEP_PEER_OFFER (value TBD). The Identification data item TLV is to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by
placed in the packet next, followed by any OPTIONAL Data Item TLVs any OPTIONAL Data Item TLVs the implementation supports:
the implementation supports:
Optional Data Item TLVs: Optional Data Item TLVs:
- DLEP Version - DLEP Version
- Peer Type - Peer Type
- IPv4 Address - IPv4 Address
- IPv6 Address - IPv6 Address
- Status - Status
- Heartbeat Interval - Heartbeat Interval
- Heartbeat Threshold - Heartbeat Threshold
- Link Characteristics ACK Timer - Link Characteristics ACK Timer
13. Peer Offer ACK Message 13. Peer Offer ACK Message
The Peer Offer ACK message acknowledges receipt of a Peer Offer The Peer Offer ACK message acknowledges receipt of a Peer Offer
message, and completes the router/modem session establishment for message, and completes the router/modem session establishment for
DLEP. The Peer Offer ACK message MUST be sent to unicast address of DLEP. The Peer Offer ACK message MUST be sent to unicast address of
the originator of a Peer Offer message. The Peer Offer ACK message the originator of a Peer Offer message. The Peer Offer ACK message
MAY contain an OPTIONAL Status data item, indicating success or MUST contain an OPTIONAL Status data item, indicating success or
failure of the attempt to establish a router/modem session. For failure of the attempt to establish a router/modem session.
implementations that do NOT support the Status data item (defined in
section 10.13 of this document), the Peer Offer ACK message MUST be
used ONLY to indicate successful session establishment; Peer Offer
messages that are rejected MUST be silently dropped, allowing the
Peer Offer to time out.
To construct a Peer Offer ACK message, the initial TLV type value is To construct a Peer Offer ACK message, the initial TLV type value is
set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are
placed into the packet next: placed into the packet next:
Mandatory Data Item TLVs: Mandatory Data Item TLVs:
- Identification
- Status - Status
Note that there are NO OPTIONAL data item TLVs specifed for this Note that there are NO OPTIONAL data item TLVs specified for this
message. message.
14. Peer Update Message 14. Peer Update Message
The Peer Update message is an OPTIONAL message, sent by a DLEP peer The Peer Update message is an OPTIONAL message, sent by a DLEP peer
to indicate local Layer 3 address changes, or for metric changes on a to indicate local Layer 3 address changes, or for metric changes on a
modem-wide basis. For example, addition of an IPv4 address to the modem-wide basis. For example, addition of an IPv4 address to the
router would prompt a Peer Update message to its attached DLEP router would prompt a Peer Update message to its attached DLEP
modems. Also, a modem that changes its Maximum Data Rate for all modems. Also, a modem that changes its Maximum Data Rate for all
destinations MAY reflect that change via a Peer Update Message to its destinations MAY reflect that change via a Peer Update Message to its
skipping to change at page 30, line 44 skipping to change at page 32, line 38
for Layer 3 address changes SHOULD cease when a either participant for Layer 3 address changes SHOULD cease when a 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.
If metrics are supplied with the Peer Update message (e.g. Maximum If metrics are supplied with the Peer Update message (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 neighbors in the information base therefore MUST be applied to all neighbors in the information base
associated with the router/modem session. associated with the router/modem session.
To construct a Peer Update message, the initial TLV type value is set To construct a Peer Update message, the initial TLV type value is set
to DLEP_PEER_UPDATE (value TBD). The Identification data item TLV is to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any
placed in the packet next, followed by any OPTIONAL Data Item TLVs. OPTIONAL Data Item TLVs.
Optional Data Item TLVs: Optional Data Item TLVs:
- IPv4 Address - IPv4 Address
- IPv6 Address - IPv6 Address
- Maximum Data Rate - Maximum Data Rate (Receive)
- Current Data Rate - Maximum Data Rate (Transmit)
- Current Data Rate (Receive)
- Current Data Rate (Transmit)
- Latency - Latency
- Expected Forwarding Time - Expected Forwarding Time
- Resources - Resources (Receive)
- Relative Link Quality - Resources (Transmit)
- Relative Link Quality (Receive)
- Relative Link Quality (Transmit)
15. Peer Update ACK Message 15. Peer Update ACK Message
The Peer Update ACK message is an OPTIONAL message, and is sent by The Peer Update ACK message is an OPTIONAL message, and is sent by
implementations supporting Layer 3 address tracking and/or modem-wide implementations supporting Layer 3 address tracking and/or modem-wide
metrics to indicate whether a Peer Update Message was successfully metrics to indicate whether a Peer Update Message was successfully
processed. processed. If the Peer Update ACK is issued, it MUST contain a Status
data item, indicating the success or failure of processing the
received Peer Update.
To construct a Peer Update ACK message, the initial TLV type value is To construct a Peer Update ACK message, the initial TLV type value is
set to DLEP_PEER_UPDATE_ACK (value TBD). The Identification data item set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is
TLV is placed in the packet next, followed by any OPTIONAL TLVs the placed in the packet next, completing the Peer Update ACK.
implementation supports:
Optional Data Item TLVs: Optional Data Item TLVs:
- Status - Status
Note that there are NO OPTIONAL data item TLVs specified for this
message.
16. Peer Termination Message 16. Peer Termination Message
The Peer Termination Message is sent by a DLEP participant when the The Peer Termination Message is 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 message MUST send a Peer Termination ACK receiving a Peer Termination message MUST send a Peer Termination ACK
message to confirm the termination process. The sender of a Peer message to confirm the termination process. The sender of a Peer
Termination message is free to define its heuristics in event of a Termination message is free to define its heuristics in event of a
timeout. The receiver of a Peer Termination Message MUST release all timeout. The receiver of a Peer Termination Message MUST release all
resources allocated for the router/modem session, and MUST eliminate resources allocated for the router/modem session, and MUST eliminate
all neighbors in the information base accessible via the router/modem all neighbors 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 Neighbor Down messages are returned to the "discovery" state. No Neighbor Down messages are
sent. sent.
To construct a Peer Termination message, the initial TLV type value To construct a Peer Termination message, the initial TLV type value
is set to DLEP_PEER_TERMINATION (value TBD). The Identification data is set to DLEP_PEER_TERMINATION (value TBD). The Signal TLV is
item TLV is placed in the packet next, followed by any OPTIONAL Data followed by any OPTIONAL Data Item TLVs the implementation supports:
Item TLVs the implementation supports:
Optional Data Item TLVs: Optional Data Item TLVs:
- Status - Status
17. Peer Termination ACK Message 17. Peer Termination ACK Message
The Peer Termination Message ACK is sent by a DLEP peer in response The Peer Termination Message ACK is sent by a DLEP peer in response
to a received Peer Termination order. Receipt of a Peer Termination to a received Peer Termination order. Receipt of a Peer Termination
ACK message completes the teardown of the router/modem session. ACK message completes the teardown of the router/modem session.
skipping to change at page 32, line 31 skipping to change at page 34, line 32
detected, or by the router, to indicate the presence of a new logical detected, or by the router, to indicate the presence of a new logical
destination (e.g., a Multicast group) exists in the network. destination (e.g., a Multicast group) exists in the network.
The sender of the Neighbor Up Message is free to define its retry The sender of the Neighbor Up Message is free to define its retry
heuristics in event of a timeout. When a Neighbor Up message is heuristics in event of a timeout. When a Neighbor Up message is
received and successfully parsed, the receiver should add knowledge received and successfully parsed, the receiver should add knowledge
of the new destination to its information base, indicating that the of the new destination to its information base, indicating that the
destination is accessible via the modem/router pair. destination is accessible via the modem/router pair.
To construct a Neighbor Up message, the initial TLV type value is set To construct a Neighbor Up message, the initial TLV type value is set
to DLEP_NEIGHBOR_UP (value TBD). The Identification data item TLV is to DLEP_NEIGHBOR_UP (value TBD). The MAC Address data item TLV is
placed in the packet next, followed by the MAC Address TLV, placed in the packet next, followed by any supported OPTIONAL Data
indicating the MAC address of the remote node or Multicast group. The Item TLVs into the packet:
implementation would then place any supported OPTIONAL Data Item TLVs
into the packet:
Optional Data Item TLVs: Optional Data Item TLVs:
- IPv4 Address - IPv4 Address
- IPv6 Address - IPv6 Address
- Maximum Data Rate - Maximum Data Rate (Receive)
- Current Data Rate - Maximum Data Rate (Transmit)
- Current Data Rate (Receive)
- Current Data Rate (Transmit)
- Latency - Latency
- Expected Forwarding Time - Expected Forwarding Time
- Resources - Resources (Receive)
- Relative Link Factor - Resources (Transmit)
- Relative Link Factor (Receive)
- Relative Link Factor (Transmit)
- Credit Window Status - Credit Window Status
19. Neighbor Up ACK Message 19. Neighbor Up ACK Message
A DLEP participant sends the Neighbor Up ACK Message to indicate A DLEP participant sends the Neighbor Up ACK Message to indicate
whether a Neighbor Up Message was successfully processed. whether a Neighbor Up Message was successfully processed.
To construct a Neighbor Up ACK message, the initial TLV type value is To construct a Neighbor Up ACK message, the initial TLV type value is
set to DLEP_NEIGHBOR_UP_ACK (value TBD). The Identification data item set to DLEP_NEIGHBOR_UP_ACK (value TBD). The MAC Address data item
TLV is placed in the packet next, followed by the MAC Address TLV, TLV is placed in the packet next, containing the MAC address of the
containing the MAC address of the DLEP neighbor. The implementation DLEP neighbor. The implementation would then place any supported
would then place any supported OPTIONAL Data Item TLVs into the OPTIONAL Data Item TLVs into the packet:
packet:
Optional Data Item TLVs: Optional Data Item TLVs:
- Credit Window Status - Credit Window Status
20. Neighbor Down Message 20. Neighbor Down Message
A DLEP peer sends the Neighbor Down message to report when a A DLEP peer sends the Neighbor Down message 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. The Neighbor Down message MUST contain both the reachable. The Neighbor Down message MUST contain the MAC Address
Identification data item TLV, and a MAC Address data item TLV. Other data item TLV. Other TLVs as listed are OPTIONAL, and MAY be present
TLVs as listed are OPTIONAL, and MAY be present if an implementation if an implementation supports them. A Neighbor Down ACK Message MUST
supports them. A Neighbor Down ACK Message MUST be sent by the be sent by the recipient of a Neighbor Down message to confirm that
recipient of a Neighbor Down message to confirm that the relevant the relevant data has been removed from the information base. The
data has been removed from the information base. The sender of the sender of the Neighbor Down message is free to define its retry
Neighbor Down message is free to define its retry heuristics in event heuristics in event of a timeout.
of a timeout.
To construct a Neighbor Down message, the initial TLV type value is To construct a Neighbor Down message, the initial TLV type value is
set to DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by set to DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by
the mandatory data item TLVs: the mandatory MAC Address data item TLV.
- Identification
- MAC Address Data item
- Status data item
Note that there are NO OPTIONAL data item TLVs for this message. Note that there are NO OPTIONAL data item TLVs for this message.
21. Neighbor Down ACK Message 21. Neighbor Down ACK Message
A DLEP participant sends the Neighbor Down ACK Message to indicate A DLEP participant sends the Neighbor Down ACK Message to indicate
whether a received Neighbor Down Message was successfully processed. whether a received Neighbor Down Message was successfully processed.
If successfully processed, the sender of the ACK MUST have removed If successfully processed, the sender of the ACK MUST have removed
all entries in the information base that pertain to the referenced all entries in the information base that pertain to the referenced
neighbor. As with the Neighbor Down message, there are NO OPTIONAL neighbor. As with the Neighbor Down message, there are NO OPTIONAL
Data Item TLVs defined for the Neighbor Down ACK message. Data Item TLVs defined for the Neighbor Down ACK message.
To construct a Neighbor Down message, the initial TLV type value is To construct a Neighbor Down message, the initial TLV type value is
set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The Identification data set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The mandatory data item
item TLV is placed in the packet next, followed by: TLVs follow:
- MAC Address Data item - MAC Address Data item
- Status data item - Status data item
22. Neighbor Update Message 22. Neighbor Update Message
A DLEP participant sends the Neighbor Update message when it detects A DLEP participant sends the Neighbor Update message when it detects
some change in the information base for a given neighbor (remote node some change in the information base for a given neighbor (remote node
or multicast group). Some examples of changes that would prompt a or multicast group). Some examples of changes that would prompt a
Neighbor Update message are: Neighbor Update message are:
- Change in link metrics (e.g., Data Rates) - Change in link metrics (e.g., Data Rates)
- Layer 3 addressing change (for implementations that support it) - Layer 3 addressing change (for implementations that support it)
To construct a Neighbor Update message, the initial TLV type value is To construct a Neighbor Update message, the initial TLV type value is
set to DLEP_NEIGHBOR_UPDATE (value TBD). Following the signal TLV are set to DLEP_NEIGHBOR_UPDATE (value TBD). Following the signal TLV are
the mandatory Data Item TLVs: the mandatory Data Item TLVs:
Identification Data Item TLV
MAC Address data item TLV MAC Address data item TLV
After placing the mandatory data item TLVs into the packet, the After placing the mandatory data item TLV into the packet, the
implementation would place any supported OPTIONAL data item TLVs. implementation would place any supported OPTIONAL data item TLVs.
Possible OPTIONAL data item TLVs are: Possible OPTIONAL data item TLVs are:
- IPv4 Address - IPv4 Address
- IPv6 Address - IPv6 Address
- Maximum Data Rate - Maximum Data Rate (Receive)
- Current Data Rate - Maximum Data Rate (Transmit)
- Current Data Rate (Receive)
- Current Data Rate (Transmit)
- Latency - Latency
- Resources - Resources (Receive)
- Relative Link Quality - Resources (Transmit)
- Relative Link Quality (Receive)
- Relative Link Quality (Transmit)
- Credit Window Status - Credit Window Status
- Credit Grant - Credit Grant
- Credit Request - Credit Request
23. Heartbeat Message 23. Heartbeat Message
A Heartbeat Message is sent by a DLEP participant every N seconds, A Heartbeat Message is sent by a DLEP participant every N seconds,
where N is defined in the "Heartbeat Interval" field of the discovery where N is defined in the "Heartbeat Interval" field of the discovery
message. Note that implementations omitting the Heartbeat Interval message. Note that implementations omitting the Heartbeat Interval
effectively set the interval to an infinite value, therefore, in effectively set the interval to an infinite value, therefore, in
those cases, this message would NOT be sent. those cases, this message would NOT be sent.
The message is used by participants to detect when a DLEP session The message 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 some integral number of heartbeat intervals Participants SHOULD allow some integral number of heartbeat intervals
(default 4) to expire with no traffic on the router/modem session (default 4) to expire with no traffic on the router/modem session
before initiating DLEP session termination procedures. before initiating DLEP session termination procedures.
To construct a Heartbeat message, the initial TLV type value is set To construct a Heartbeat message, the initial TLV type value is set
to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the
mandatory data item TLVs: mandatory Heartbeat Interval/Threshold data item.
- Identification
Note that there are NO OPTIONAL data item TLVs for this message. Note that there are NO OPTIONAL data item TLVs for this message.
24. Link Characteristics Request Message 24. Link Characteristics Request Message
The Link Characteristics Request Message is an OPTIONAL message, and The Link Characteristics Request Message is an OPTIONAL message, and
is sent by the router to request that the modem initiate changes for is sent by the router to request that the modem initiate changes for
specific characteristics of the link. Since the request specifies a specific characteristics of the link. Since the request specifies a
neighbor, it can reference either a real destination (e.g., a remote neighbor, it can reference either a real destination (e.g., a remote
node), or a logical destination (e.g., a multicast destination) node), or a logical destination (e.g., a multicast destination)
within the network. within the network.
The Link Characteristics Request message contains either a Current The Link Characteristics Request message contains either a Current
Data Rate (CDR) TLV to request a different amount of bandwidth than Data Rate (CDRR or CDRT) TLV to request a different amount of
what is currently allocated, a Latency TLV to request that traffic bandwidth than what is currently allocated, a Latency TLV to request
delay on the link not exceed the specified value, or both. A Link that traffic delay on the link not exceed the specified value, or
Characteristics ACK Message is required to complete the request. both. A Link Characteristics ACK Message is required to complete the
Implementations are free to define their retry heuristics in event of request. Implementations are free to define their retry heuristics in
a timeout. Issuing a Link Characteristics Request with ONLY the MAC event of a timeout. Issuing a Link Characteristics Request with ONLY
Address TLV is a mechanism a peer MAY use to request metrics (via the the MAC Address TLV is a mechanism a peer MAY use to request metrics
Link Characteristics ACK) from its partner. (via the Link Characteristics ACK) from its partner.
To construct a Link Characteristics Request message, the initial TLV To construct a Link Characteristics Request message, the initial TLV
type value is set to DLEP_NEIGHBOR_LINK_CHAR_REQ (value TBD). type value is set to DLEP_NEIGHBOR_LINK_CHAR_REQ (value TBD).
Following the signal TLV are the mandatory Data Item TLVs: Following the signal TLV is the mandatory Data Item TLV:
Identification Data Item TLV
MAC Address data item TLV MAC Address data item TLV
After placing the mandatory data item TLVs into the packet, the After placing the mandatory data item TLV into the packet, the
implementation would place any supported OPTIONAL data item TLVs. implementation would place any supported OPTIONAL data item TLVs.
Possible OPTIONAL data item TLVs are: Possible OPTIONAL data item TLVs are:
Current Data Rate - If present, this value represents the NEW (or Current Data Rate - If present, this value represents the NEW (or
unchanged, if the request is denied) Current unchanged, if the request is denied) Current
Data Rate in bits per second (bps). Data Rate in bits per second (bps).
Latency - If present, this value represents the maximum Latency - If present, this value represents the maximum
desired latency (e.g., it is a not-to-exceed desired latency (e.g., it is a not-to-exceed
value) in milliseconds on the link. value) in milliseconds on the link.
skipping to change at page 36, line 7 skipping to change at page 38, line 4
Current Data Rate - If present, this value represents the NEW (or Current Data Rate - If present, this value represents the NEW (or
unchanged, if the request is denied) Current unchanged, if the request is denied) Current
Data Rate in bits per second (bps). Data Rate in bits per second (bps).
Latency - If present, this value represents the maximum Latency - If present, this value represents the maximum
desired latency (e.g., it is a not-to-exceed desired latency (e.g., it is a not-to-exceed
value) in milliseconds on the link. value) in milliseconds on the link.
25. Link Characteristics ACK Message 25. Link Characteristics ACK Message
The LInk Characteristics ACK message is an OPTIONAL message, and is The LInk Characteristics ACK message is an OPTIONAL message, and is
sent by modems supporting it to the router letting the router know sent by modems supporting it to the router letting the router know
the success or failure of a requested change in link characteristics. the success or failure of a requested change in link characteristics.
The Link Characteristics ACK message SHOULD contain a complete set The Link Characteristics ACK message SHOULD contain a complete set
of metric data item TLVs. It MUST contain the same TLV types as the of metric data item TLVs. It MUST contain the same TLV types as the
request. The values in the metric data item TLVs in the Link request. The values in the metric data item TLVs in the Link
Characteristics ACK message MUST reflect the link characteristics Characteristics ACK message MUST reflect the link characteristics
after the request has been processed. after the request has been processed.
To construct a Link Characteristics Request ACK message, the initial To construct a Link Characteristics Request ACK message, the initial
TLV type value is set to DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD). TLV type value is set to DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD).
Following the signal TLV are the mandatory Data Item TLVs: Following the signal TLV is the mandatory Data Item TLV:
Identification Data Item TLV
MAC Address data item TLV MAC Address data item TLV
After placing the mandatory data item TLVs into the packet, the After placing the mandatory data item TLV into the packet, the
implementation would place any supported OPTIONAL data item TLVs. implementation would place any supported OPTIONAL data item TLVs.
Possible OPTIONAL data item TLVs are: Possible OPTIONAL data item TLVs are:
Current Data Rate - If present, this value represents the requested Current Data Rate - If present, this value represents the requested
data rate in bits per second (bps). data rate in bits per second (bps).
Latency - If present, this value represents the NEW Latency - If present, this value represents the NEW
maximum latency (or unchanged, if the request maximum latency (or unchanged, if the request
is denied), expressed in milliseconds, on the is denied), expressed in milliseconds, on the
link. link.
skipping to change at page 37, line 10 skipping to change at page 39, line 5
27.1 Registrations 27.1 Registrations
This specification defines: This specification defines:
o A new repository for DLEP signals, with fifteen values currently o A new repository for DLEP signals, with fifteen values currently
assigned. assigned.
o Reservation of numbering space for Experimental DLEP signals. o Reservation of numbering space for Experimental DLEP signals.
o A new repository for DLEP Data Items, with eighteen values o A new repository for DLEP Data Items, with twenty-one values
currently assigned. currently assigned.
o Reservation of numbering space in the Data Items repository for o Reservation of numbering space in the Data Items repository for
experimental data items. experimental data items.
o A request for allocation of a well-known port for DLEP o A request for allocation of a well-known port for DLEP
communication. communication.
o A request for allocation of a multicast address for DLEP o A request for allocation of a multicast address for DLEP
discovery. discovery.
skipping to change at page 38, line 10 skipping to change at page 40, line 5
o Link Characteristics ACK o Link Characteristics ACK
It is also requested that the repository contain space for It is also requested that the repository contain space for
experimental signal types. experimental signal types.
27.4 DLEP Data Item Registrations 27.4 DLEP Data Item Registrations
A new repository for DLEP Data Items must be created. Valid Data A new repository for DLEP Data Items must be created. Valid Data
Items are: Items are:
o Identification
o DLEP Version o DLEP Version
o Peer Type o Peer Type
o MAC Address o MAC Address
o IPv4 Address o IPv4 Address
o IPv6 Address o IPv6 Address
o Maximum Data Rate o Maximum Data Rate (Receive)
o Current Data Rate o Maximum Data Rate (Transmit)
o Current Data Rate (Receive)
o Current Data Rate (Transmit)
o Latency o Latency
o Expected Forwarding Time o Expected Forwarding Time
o Resources o Resources (Receive)
o Relative Link Quality o Resources (Transmit)
o Relative Link Quality (Receive)
o Relative Link Quality (Transmit)
o Status o Status
o Heartbeat Interval/Threshold o Heartbeat Interval/Threshold
o Link Characteristics ACK Timer o Link Characteristics ACK Timer
o Credit Window Status o Credit Window Status
o Credit Grant o Credit Grant
o Credit Request o Credit Request
It is also requested that the registry allocation contain space for It is also requested that the registry allocation contain space for
experimental data items. experimental data items.
skipping to change at page 39, line 4 skipping to change at page 40, line 48
discovery messages. discovery messages.
30. Appendix A. 30. Appendix A.
30.1 Peer Level Message Flows 30.1 Peer Level Message Flows
30.1.1 Modem Device Restarts Discovery 30.1.1 Modem Device Restarts Discovery
Router Modem Message Description Router Modem Message Description
==================================================================== ====================================================================
<-------Peer Discovery--------- Modem initiates discovery
<-------Peer Discovery--------- Modem initiates discovery
---------Peer Offer-----------> Router detects a problem, sends ---------Peer Offer-----------> Router detects a problem, sends
w/ Non-zero Status TLV Peer Offer w/Status TLV indicating w/ Non-zero Status TLV Peer Offer w/Status TLV indicating
the error. the error.
Modem accepts failure, restarts Modem accepts failure, restarts
discovery process. discovery process.
<-------Peer Discovery--------- Modem initiates discovery <-------Peer Discovery--------- Modem initiates discovery
---------Peer Offer-----------> Router accepts, sends Peer Offer ---------Peer Offer-----------> Router accepts, sends Peer Offer
skipping to change at page 46, line 44 skipping to change at page 48, line 44
EMail: greharri@cisco.com EMail: greharri@cisco.com
Shawn Jury Shawn Jury
NetApp NetApp
7301 Kit Creek Road, Building 2 7301 Kit Creek Road, Building 2
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: shawn.jury@netapp.com Email: shawn.jury@netapp.com
Darryl Satterwhite Darryl Satterwhite
Cisco Broadcom
170 West Tasman Drive
San Jose, CA 95134
USA USA
Email: dsatterw@cisco.com Email: dsatterw@broadcom.com
 End of changes. 111 change blocks. 
363 lines changed or deleted 444 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/