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