< draft-ietf-manet-dlep-02.txt		draft-ietf-manet-dlep-03.txt >
	Mobile Ad hoc Networks Working S. Ratliff		Mobile Ad hoc Networks Working S. Ratliff
	Group B. Berry		Group B. Berry
	Internet-Draft G. Harrison		Internet-Draft G. Harrison
	Intended status: Standards Track D. Satterwhite		Intended status: Standards Track D. Satterwhite
	Expires: August 10, 2012 Cisco Systems		Expires: March 3, 2013 Cisco Systems
	S. Jury		S. Jury
	NetApp		NetApp
	February 6, 2012		August 30, 2012
	Dynamic Link Exchange Protocol (DLEP)		Dynamic Link Exchange Protocol (DLEP)
	draft-ietf-manet-dlep-02		draft-ietf-manet-dlep-03
	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 47 ¶		skipping to change at page 1, line 48 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 10, 2012 .		This Internet-Draft will expire on February 21, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
	2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 8		5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 10
	6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 8		6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . . 10
	7. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 9		7. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 12
	8. Message Header Format . . . . . . . . . . . . . . . . . . . . 10		8. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 13
	9. Message TLV Block Format . . . . . . . . . . . . . . . . . . . 10		9. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . . 13
	10. DLEP Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 11		9.1 Identification . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Identification Sub-TLV. . . . . . . . . . . . . . . . . . 12		9.2 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 15
	10.2. DLEP Version Sub-TLV. . . . . . . . . . . . . . . . . . . 13		9.3 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.3. Peer Type Sub-TLV . . . . . . . . . . . . . . . . . . . . 14		9.4 MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.4. MAC Address Sub-TLV . . . . . . . . . . . . . . . . . . . 14		9.5 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 17
	10.5. IPv4 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 15		9.6 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 18
	10.6. IPv6 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 16		9.7 Maximum Data Rate . . . . . . . . . . . . . . . . . . . . . 18
	10.7. Maximum Data Rate Sub-TLV . . . . . . . . . . . . . . . . 16		9.8 Current Data Rate . . . . . . . . . . . . . . . . . . . . . 19
	10.8. Current Data Rate Sub-TLV . . . . . . . . . . . . . . . . 17		9.9 Expected Forwarding Time . . . . . . . . . . . . . . . . . 20
	10.9. Latency Sub-TLV . . . . . . . . . . . . . . . . . . . . . 18		9.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.10. Resources Sub-TLV . . . . . . . . . . . . . . . . . . . . 18		9.11 Resources . . . . . . . . . . . . . . . . . . . . . . . . 21
	10.11. Expected Forwarding Time Sub-TLV. . . . . . . . . . . . . 19		9.12 Relative Link Quality . . . . . . . . . . . . . . . . . . 22
	10.12. Relative Link Quality Sub-TLV . . . . . . . . . . . . . . 20		9.13 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.13. Peer Termination Sub-TLV. . . . . . . . . . . . . . . . . 20		9.14 Heartbeat Interval/Threshold . . . . . . . . . . . . . . . 23
	10.14. Heartbeat Interval Sub-TLV. . . . . . . . . . . . . . . . 21		9.15 Link Characteristics ACK Timer . . . . . . . . . . . . . . 24
	10.15. Heartbeat Threshold Sub-TLV . . . . . . . . . . . . . . . 21		9.16 Credit Window Status . . . . . . . . . . . . . . . . . . . 24
	10.16. Link Characteristics ACK Timer Sub-TLV. . . . . . . . . . 22		9.17 Credit Grant Request . . . . . . . . . . . . . . . . . . . 25
	10.17. Credit Window Status Sub-TLV. . . . . . . . . . . . . . . 23		9.18 Credit Request . . . . . . . . . . . . . . . . . . . . . . 26
	10.18. Credit Grant Sub-TLV. . . . . . . . . . . . . . . . . . . 24		10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 27
	10.19. Credit Request Sub-TLV. . . . . . . . . . . . . . . . . . 24		10.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 27
	11. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . 25		11. Peer Discovery Message . . . . . . . . . . . . . . . . . . . . 28
	11.1. Message Block TLV Values . . . . . . . . . . . . . . . . 25		12. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 28
	12. Peer Discovery Messages . . . . . . . . . . . . . . . . . . . 26		13. Peer Offer ACK Message . . . . . . . . . . . . . . . . . . . . 29
	12.1. Attached Peer Discovery Message . . . . . . . . . . . . . 26		14. Peer Update Message . . . . . . . . . . . . . . . . . . . . . 30
	12.2. Detached Peer Discovery Message . . . . . . . . . . . . . 27		15. Peer Update ACK Message . . . . . . . . . . . . . . . . . . . 31
	13. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 29		16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 31
	14. Peer Update Message. . . . . . . . . . . . . . . . . . . . . . 30		17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 31
	15. Peer Update ACK Message. . . . . . . . . . . . . . . . . . . . 31		18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 32
	16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 32		19. Neighbor Up ACK Message . . . . . . . . . . . . . . . . . . . 32
	17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 33		20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 33
	18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 33		21. Neighbor Down ACK Message . . . . . . . . . . . . . . . . . . 33
	19. Neighbor Up ACK Message. . . . . . . . . . . . . . . . . . . . 35		22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 34
	20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 35		23. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 34
	21. Neighbor Down ACK Message. . . . . . . . . . . . . . . . . . . 36		24. Link Characteristics Request Message . . . . . . . . . . . . . 35
	22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 37		25. Link Characteristics ACK Message . . . . . . . . . . . . . . . 36
	23. Neighbor Address Update Message. . . . . . . . . . . . . . . . 38		26. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	24. Neighbor Address Update ACK Message. . . . . . . . . . . . . . 39		27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	25. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 40		27.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 36
	26. Link Characteristics Message . . . . . . . . . . . . . . . . . 40		27.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 37
	27. Link Characteristics ACK Message . . . . . . . . . . . . . . . 42		27.3 Signal (Message) TLV Type Registration . . . . . . . . . . 37
	28. Security Considerations. . . . . . . . . . . . . . . . . . . . 43		27.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 38
	29. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 43		27.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 38
	29.1 TLV Registrations. . . . . . . . . . . . . . . . . . . . . 43		27.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 38
	29.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 43		30. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 38
	29.3 Message TLV Type Registrations . . . . . . . . . . . . . . 43		30.1 Peer Level Message Flows . . . . . . . . . . . . . . . . . 38
	29.4 DLEP Order Registrations . . . . . . . . . . . . . . . . . 44		30.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 38
	29.5 DLEP Sub-TLV Type Registrations. . . . . . . . . . . . . . 44		30.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 39
	30. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 45		30.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 40
			30.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 40
			30.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 41
			30.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 41
			30.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 42
			30.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 42
			30.2 Neighbor Specific Message Flows . . . . . . . . . . . . . 42
			30.2.1 Modem Neighbor Up Lost . . . . . . . . . . . . . . . . 43
			30.2.2 Router Detects Duplicate Neighbor Ups . . . . . . . . 43
			30.2.3 Neighbor Up, No Layer 3 Addresses . . . . . . . . . . 44
			30.2.4 Neighbor Up with IPv4, No IPv6 . . . . . . . . . . . . 44
			30.2.5 Neighbor Up with IPv4 and IPv6 . . . . . . . . . . . . 44
			30.2.6 Neighbor Session Success . . . . . . . . . . . . . . . 45
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 45
			Normative References . . . . . . . . . . . . . . . . . . . . . . . 45
			Informative References . . . . . . . . . . . . . . . . . . . . . . 46
			Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	There exist today a collection of modem devices that control links of		There exist today a collection of modem devices that control links of
	variable bandwidth and quality. Examples of these types of links		variable bandwidth and quality. Examples of these types of links
	include line-of-sight (LOS) radios, satellite terminals, and cable/		include line-of-sight (LOS) radios, satellite terminals, and
	DSL modems. Fluctuations in speed and quality of these links can		cable/DSL modems. Fluctuations in speed and quality of these links
	occur due to configuration (in the case of cable/DSL modems), or on a		can occur due to configuration (in the case of cable/DSL modems), or
	moment-to-moment basis, due to physical phenomena like multipath		on a moment-to-moment basis, due to physical phenomena like multipath
	interference, obstructions, rain fade, etc. It is also quite possible		interference, obstructions, rain fade, etc. It is also quite possible
	that link quality and bandwidth varies with respect to individual		that link quality and bandwidth varies with respect to individual
	neighbors on a link, and with the type of traffic being sent. As an		neighbors on a link, and with the type of traffic being sent. As an
	example, consider the case of an 802.11g access point, serving 2		example, consider the case of an 802.11g access point, serving 2
	associated laptop computers. In this environment, the answer to the		associated laptop computers. In this environment, the answer to the
	question "What is the bandwidth on the 802.11g link?" is "It depends		question "What is the bandwidth on the 802.11g link?" is "It depends
	on which associated laptop we're talking about, and on what kind of		on which associated laptop we're talking about, and on what kind of
	traffic is being sent." While the first laptop, being physically		traffic is being sent." While the first laptop, being physically
	close to the access point, may have a bandwidth of 54Mbps for		close to the access point, may have a bandwidth of 54Mbps for unicast
	unicast traffic, the other laptop, being relatively far away, or		traffic, the other laptop, being relatively far away, or obstructed
	obstructed by some object, can simultaneously have a bandwidth of		by some object, can simultaneously have a bandwidth of only 32Mbps
	only 32Mbps for unicast. However, for multicast traffic sent from the		for unicast. However, for multicast traffic sent from the access
	access point, all traffic is sent at the base transmission rate		point, all traffic is sent at the base transmission rate (which is
	(which is configurable, but depending on the model of the access		configurable, but depending on the model of the access point, is
	point, is usually 24Mbps or less).		usually 24Mbps or less).
	In addition to utilizing variable bandwidth links, mobile networks		In addition to utilizing variable bandwidth links, mobile networks
	are challenged by the notion that link connectivity will come and go		are challenged by the notion that link connectivity will come and go
	over time. Effectively utilizing a relatively short-lived connection		over time. Effectively utilizing a relatively short-lived connection
	is problematic in IP routed networks, as routing protocols tend to		is problematic in IP routed networks, as routing protocols tend to
	rely on independent timers at OSI Layer 3 to maintain network		rely on independent timers at OSI Layer 3 to maintain network
	convergence (e.g. HELLO messages and/or recognition of DEAD routing		convergence (e.g. HELLO messages and/or recognition of DEAD routing
	adjacencies). These short-lived connections can be better utilized		adjacencies). These short-lived connections can be better utilized
	with an event-driven paradigm, where acquisition of a new neighbor		with an event-driven paradigm, where acquisition of a new neighbor
	(or loss of an existing one) is somehow signaled, as opposed to a		(or loss of an existing one) is signaled, as opposed to a timer-
	timer-driven paradigm.		driven paradigm.
	Another complicating factor for mobile networks are the different		Another complicating factor for mobile networks are the different
	methods of physically connecting the modem devices to the router.		methods of physically connecting the modem devices to the router.
	Modems can be deployed as an interface card in a router's		Modems can be deployed as an interface card in a router's chassis, or
	chassis, or as a standalone device connected to the router via		as a standalone device connected to the router via Ethernet, USB, or
	Ethernet, USB, or even a serial link. In the case of Ethernet or		even a serial link. In the case of Ethernet or serial attachment,
	serial attachment, with existing protocols and techniques, routing		with existing protocols and techniques, routing software cannot be
	software cannot be aware of convergence events occurring on the		aware of convergence events occurring on the radio link (e.g.
	radio link (e.g. acquisition or loss of a potential routing		acquisition or loss of a potential routing neighbor), nor can the
	neighbor), nor can the router be aware of the actual capacity of		router be aware of the actual capacity of the link. This lack of
	the link. This lack of awareness, along with the variability in		awareness, along with the variability in bandwidth, leads to a
	bandwidth, leads to a situation where quality of service (QoS)		situation where quality of service (QoS) profiles are extremely
	profiles are extremely difficult to establish and properly		difficult to establish and properly maintain. This is especially true
	maintain. This is especially true of demand-based access schemes		of demand-based access schemes such as Demand Assigned Multiple
	such as Demand Assigned Multiple Access (DAMA) implementations		Access (DAMA) implementations used on some satellite systems. With a
	used on some satellite systems. With a DAMA-based system,		DAMA-based system, additional bandwidth may be available, but will
	additional bandwidth may be available, but will not be used		not be used unless the network devices emit traffic at rate higher
	unless the network devices emit traffic at rate higher than the		than the currently established rate. Increasing the traffic rate does
	currently established rate. Increasing the traffic rate does not		not guarantee additional bandwidth will be allocated; rather, it may
	guarantee additional bandwidth 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.
	In attempting to address the challenges listed above, the authors		Addressing the challenges listed above, the authors have developed
	have developed the Data Link Exchange Protocol, or DLEP. The DLEP		the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs
	protocol runs between a router and its attached modem devices,		between a router and its attached modem devices, allowing the modem
	allowing the modem to communicate link characteristics as they		to communicate link characteristics as they change, and convergence
	change, and convergence events (acquisition and loss of potential		events (acquisition and loss of potential routing neighbors). The
	routing neighbors). The following diagrams are used to illustrate		following diagrams are used to illustrate the scope of DLEP packets.
	the scope of DLEP sessions.
	|-----Local Neighbor-----| |-----Remote Neighbor----|
	| | | (far-end device) |
			|-------Local Node-------| |-------Remote Node------|
			| | | |
	+--------+ +-------+ +-------+ +--------+		+--------+ +-------+ +-------+ +--------+
	| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |		| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
	| | | Device| | Device| | |		| | | Device| | Device| | |
	+--------+ +-------+ +-------+ +--------+		+--------+ +-------+ +-------+ +--------+
	| | | 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 a local client (Modem device) detects the		In Figure 1, when the local modem detects the presence of a remote
	presence of a remote neighbor, it sends an indication to its		node, it (the local modem) sends a signal to its router via the DLEP
	local router via the DLEP session. Upon receipt of the indication,		protocol. Upon receipt of the signal, the local router may take
	the local router would take appropriate action (e.g. initiation		whatever action it deems appropriate, such as initiating discovery
	of discovery or HELLO protocols) to converge the network. After		protocols, and/or issuing HELLO messages to converge the network. On
	notification of the new neighbor, the modem device utilizes the		a continuing, as-needed basis, the modem devices utilize DLEP to
	DLEP session to report the characteristics of the link (bandwidth,		report any characteristics of the link (bandwidth, latency, etc) that
	latency, etc) to the router on an as-needed basis.		have changed. DLEP is independent of the link type and topology
			supported by the modem.
	DLEP is independent of the underlying link type and topology.		Figure 2 shows how DLEP can support a configuration where routers are
	Figure 2 shows how DLEP can support a configuration whereby		connected with different link types. In this example, Modem A
	routers are connected with different link types and with different		implements a point-to-point link, and Modem B is connected via a
	network configurations. In this setup, the routers are connected		shared medium. In both cases, the DLEP protocol is used to report the
	with two different devices (Modem device A and Modem device B).		characteristics of the link (bandwidth, latency, etc.) to routers.
	Modem A is connected via a point-to-point link, whereas Modem B		The modem is also able to use the DLEP session to notify the router
	is connected via a shared medium. In both cases, the DLEP session		when the remote node is lost, shortening the time required to re-
	is used to report the characteristics of the link (bandwidth,		converge the network.
	latency, etc.) to network neighbors on an as-needed basis. The
	modem is also able to use the DLEP session to notify the router
	when the remote neighbor is lost, shortening the time required to
	re-converge the network.
	+--------+ +--------+		+--------+ +--------+
	+------+ Modem A| | Modem A+-----+		+----+ Modem A| | Modem A+---+
	| | Device | <===== // ======> | Device | |		| | Device | <===== // ======> | Device | |
	| +--------+ P-t-P Link +--------+ |		| +--------+ P-2-P Link +--------+ |
	| Protocol |		+---+----+ +---+----+
	+---+----+ +---+----+		| Router | | Router |
	| Router | | Router |		| | | |
	| | | |		+---+----+ +---+----+
	+---+----+ +---+----+		| +--------+ +--------+ |
	| +		+-----+ Modem B| | Modem B| |
	| +--------+ +--------+ |		| Device | o o o o o o o o | Device +--+
	+------+ Modem B| | Modem B| |		+--------+ o Shared o +--------+
	| Device | o o o o o o o o | Device +-----+		o Medium o
	+--------+ o Shared o +--------+		o o
	o Medium o		o o
	o o		o o
	o o		o
	o o		+--------+
	o		| Modem B|
	+--------+		| Device |
	| Modem B|		+---+----+
	| Device |		|
	+---+----+		|
	|		+---+----+
	|		| Router |
	+---+----+		| |
	| Router |		+--------+
	| |
	+--------+
	Figure 2: DLEP Network with Multiple Modem Devices		Figure 2: DLEP Network with Multiple Modem Devices
	DLEP exists as a collection of type-length-value (TLV) based messages		DLEP defines a set of logical signals used by modems and their
	using [RFC5444] formatting. The protocol can be used for both Ethernet		attached routers. The signals are used to communicate events that
	attached modems (utilizing, for example, a UDP socket for transport		occur on the physical link(s) managed by the modem: for example, a
	of the RFC 5444 packets), or in environments where the modem is an		remote node entering or leaving the network, or that the link has
	interface card in a chassis (via a message passing scheme). DLEP		changed. Associated with these signals are a set of data items -
	utilizes a session paradigm between the modem device and its		information that describes the remote node (e.g., address
	associated router. If multiple modem devices are attached to a		information), and/or the characteristics of the link to the remote
	router (as in FIgure 2), a separate DLEP session MUST exist for each		node.
			The protocol is defined as a collection of type-length-value (TLV)
			based messages, specifying the signals that are exchanged between a
			router and a modem, and the data items associated with the signal.
			This document specifies transport of DLEP signals and data items via
			the UDP transport. Other transports for the protocol are possible,
			but are outside the scope of this document.
			DLEP signals are further defined as mandatory or optional. Signals
			will additionally have mandatory and optional data items.
			Implementations MUST support all mandatory signals and their
			mandatory data items to be considered compliant. Implementations MAY
			also support some, or all, of the optional signals and data items.
			DLEP uses a session-oriented paradigm between the modem device and
			its associated router. If multiple modem devices are attached to a
			router (as in Figure 2), a separate DLEP session MUST exist for each
	modem. If a modem device supports multiple connections to a router		modem. If a modem device supports multiple connections to a router
	(via multiple logical or physical interfaces), or supports		(via multiple logical or physical interfaces), or supports
	connections to multiple routers, a separate DLEP session MUST exist		connections to multiple routers, a separate DLEP session MUST exist
	for each connection.		for each connection. This router/modem session provides a carrier for
			information exchange concerning neighbors (remote nodes) that are
			accessible via the modem device. As such, all of the neighbor-level
			exchanges in DLEP can be envisioned as building an information base
			concerning the remote nodes, and the link characteristics to those
			nodes.
			Multicast traffic is handled in IP networks by deriving a Layer 2 MAC
			address based on the Layer 3 address. Leveraging on this scheme,
			Multicast traffic is supported in DLEP simply by treating the derived
			MAC address as any other destination in the network. To support these
			logical destinations, one of the DLEP participants (typically, the
			router) informs the other as to the existence of the logical
			neighbor. The modem, once it is aware of the existence of this
			logical neighbor, reports link characteristics just as it would for
			any other destination in the network. The specific algorithms a modem
			would use to report metrics on multicast (or logical) destinations is
			outside the scope of this specification, and is left to specific
			implementations to decide.
	1.1 Requirements		1.1 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
	In order to implement discovery in the DLEP protocol (thereby		Routers and modems that exist as part of the same node (e.g., that
	avoiding some configuration), we have defined a first-speaker and a		are locally connected) can utilize a discovery technique to locate
	passive-listener scheme. Borrowing from existing terminology, this		each other, thus avoiding a-priori configuration. Either entity (the
	document refers to the first-speaker as the 'client', and the passive		router or the modem) can initiate the discovery process. In cases
	listener as the 'server', even though there is no client/server		where both entities initiate discovery, a race condition can occur.
	relationship in the classic sense. In a typical deployment, a router		When this race condition occurs, the router MUST cease its active
	would appear as the DLEP 'server', and an attached modem device would		discovery, and respond to the modem's request.
	act as the 'client' (e.g. the initiator for discovery).
	DLEP assumes that participating clients appear to the server as a		DLEP utilizes a session-oriented paradigm. A router and modem form a
	transparent bridge - specifically, the assumption is that the		session by completing the discovery process. This router-modem
	destination MAC address for data traffic in any frame emitted by		session persists unless or until it either (1) times out, based on
	the server should be the MAC address of the next-hop router or end-		the timeout values supplied, or (2) is explicitly torn down by one of
	device, and not the MAC address of any of the intervening clients.		the participants. Note that use of timers in DLEP is OPTIONAL; that
			is, implementations can choose to run with no timers (or effectively,
			timers set to an infinite value).
	DLEP assumes that security on the session (e.g. authentication of		DLEP assumes that participating modems, and their physical links, act
	session partners, encryption of traffic, or both) is dealt with by		as a transparent bridge. Specifically, the assumption is that the
	the underlying transport mechanism for the RFC 5444 packets (e.g. by		destination MAC address for data traffic in any frame emitted by the
	using a transport such as DTLS [DTLS]).		router should be the MAC address of a device in the remote node. DLEP
			also assumes that MAC addresses are unique within the context of the
			router-modem session.
	DLEP utilizes a session-oriented paradigm. There are two classes		This document refers to a remote node as a "Neighbor". Neighbors can
	of sessions - the first is identified as a 'peer session'. The		be identified by either the router or the modem, and represent a
	peer session exists between a DLEP server and a DLEP client. All		specific destination (e.g., an address) that exists on the link(s)
	DLEP messages between client and server are transmitted within the		managed by the modem. Examples of a destination include a MAC
	context of the peer session.		address, a unicast Layer 3 address, or a multicast Layer 3 address.
			As "neighbors" are discovered, DLEP routers and modems build an
			information base on destinations accessible via the modem. Changes in
			link characteristics MAY then be reported as being "modem-wide"
			(effecting ALL neighbors accessed via the modem) or MAY be neighbor
			(destination) specific.
	The other type of DLEP session is referred to as a 'neighbor session'.		The DLEP signals concerning neighbors thus become the way for routers
	Neighbor sessions can be instantiated by either the DLEP server or		and modems to maintain, and notify each other about, an information
	client, and represent an identifiable destination (i.e. an address)		base representing the physical and logical (e.g., multicast)
	within the network. Examples of a destination would be a unicast		destinations accessible via the modem device. The information base
	address (for either a next-hop router, or for an end-station), or		would contain addressing information (e.g., MAC address, and
	a multicast address. A DLEP neighbor session MUST exist for every		OPTIONALLY, Layer 3 addresses), link characteristics (metrics), and
	destination that exists in the network.		OPTIONALLY, flow control information (credits).
	The optional [RFC5444] message header Sequence Number MUST be		DLEP assumes that security on the session (e.g. authentication of
	included in all DLEP packets. Sequence Numbers start at 1 and are		session partners, encryption of traffic, or both) is dealt with by
	incremented by one for each original and retransmitted message. The		the underlying transport mechanism (e.g., by using a transport such
	unsigned 16-bit Sequence Number rolls over at 65535 to 1. A		as DTLS [DTLS]).
	Sequence Number of 0 is not valid. Sequence Numbers are unique
			Sequence Numbers for DLEP messages start at 0 and are incremented by
			one for each original and retransmitted message. The unsigned 16-bit
			Sequence Number rolls over at 65535 to 0. Sequence Numbers are unique
	within the context of a DLEP session. Sequence numbers are used in		within the context of a DLEP session. Sequence numbers are used in
	DLEP to correlate a response to a request.		DLEP to correlate a response to a request.
			This document specifies an implementation of the DLEP signals and
			data items running over the UDP transport, utilizing a well-known UDP
			Port number. It is assumed that DLEP running over other transport
			mechanisms would be documented separately.
	3. Credits		3. Credits
	DLEP includes an OPTIONAL credit-windowing scheme analogous to the		DLEP includes an OPTIONAL credit-windowing scheme analogous to the
	one documented in [RFC5578]. In this scheme, traffic between the		one documented in [RFC5578]. In this scheme, traffic between the
	DLEP client and the DLEP server is treated as two unidirectional		router and modem is treated as two unidirectional windows. This
	windows. This document identifies these windows as the "Client		document identifies these windows as the "Modem Receive Window", or
	Receive Window", or CRW, and the "Server Receive Window", or SRW.		MRW, and the "Router Receive Window", or RRW.
	If credits are used, they MUST be granted by the receiver on a		If credits are used, they MUST be granted by the receiver on a given
	given window - that is, on the "Client Receive Window" (CRW),		window - that is, on the "Modem Receive Window" (MRW), the modem is
	the DLEP client is responsible for granting credits to the server,		responsible for granting credits to the router, allowing it (the
	allowing it (the server) to send data to the client. Likewise,		router) to send data to the modem. Likewise, the router is
	the DLEP server is responsible for granting credits on the SRW,		responsible for granting credits on the RRW, which allows the modem
	which allows the client to send data to the server.		to send data to the router.
	DLEP expresses all credit data in number of octets. The total number		DLEP expresses all credit data in number of octets. The total number
	of credits on a window, and the increment to add to a grant, are		of credits on a window, and the increment to add to a grant, are
	always expressed as a 64-bit unsigned quantity.		always expressed as a 64-bit unsigned quantity.
	If used, credits are managed on a neighbor session basis; that is,		If used, credits are managed on a neighbor-specific basis; that is,
	separate credit counts are maintained for each neighbor session		separate credit counts are maintained for each neighbor requiring the
	requiring the service. Credits do not apply to DLEP peer sessions.		service. Credits do not apply to the DLEP session that exists between
			routers and modems.
	4. Metrics		4. Metrics
	DLEP includes the ability for the client and server to communicate		DLEP includes the ability for the router and modem to communicate
	metrics that reflect the characteristics (e.g. bandwidth, latency)		metrics that reflect the characteristics (e.g. bandwidth, latency) of
	of the variable-quality link in use. As mentioned in the		the variable-quality link in use. As mentioned in the introduction
	introduction section of this document, metrics have to be used		section of this document, metrics have to be used within a context -
	within a context - for example, metrics to a unicast address in		for example, metrics to a unicast address in the network. DLEP allows
	the network. DLEP allows for metrics to be sent within two		for metrics to be sent within two contexts - metrics for a specific
	contexts - neighbor session context (those for a given destination		neighbor (those for a given destination within the network), and
	within the network), and peer session context (those that apply		"modem-wide" (those that apply to all destinations accessed via the
	to all destinations accessed via the DLEP client). Metrics		modem). Metrics supplied on DLEP Peer signals are, by definition,
	supplied on DLEP Peer messages are, by definition, in the context		modem-wide; metrics supplied on Neighbor signals are, by definition,
	of a peer session; metrics supplied on Neighbor messages are, by		used for the specific neighbor only.
	definition, used in the context of a neighbor session.
	Supplying metrics in a peer session context gives clients the		It is left to implementations to choose sensible default values based
	ability to supply default metrics on a 'device-wide' basis. It is		on their specific characteristics. Additionally, this mechanism
	left to implementations to choose sensible default values based on		(either at a modem-wide or specific neighbor context) MAY be used to
	their specific characteristics. Additionally, the metrics (either		report non-changing, or static, metrics. Modems having static link
	at a peer or neighbor session context) MAY be used to report non-		metric characteristics MAY report metrics only once for a given
	changing, or static, metrics. Clients having static link metric		neighbor (or once on a modem-wide basis, if all connections via the
	characteristics SHOULD report metrics only once for a given		modem are of this static nature).
	neighbor session (or peer session, if all connections via the client
	are of this static nature).
	The approach of allowing for different contexts for metric data		The approach of allowing for different contexts for metric data
	increases both the flexibility and the complexity of using metric		increases both the flexibility and the complexity of using metric
	data. This document details the mechanism whereby the data is		data. This document details the mechanism whereby the data is
	transmitted, however, the specific algorithms for utilizing the		transmitted, however, the specific algorithms (precedence, etc) for
	dual-context metrics is out of scope and not addressed by this		utilizing the dual-context metrics is out of scope and not addressed
	document.		by this document.
	5. Extensions to DLEP		5. Extensions to DLEP
	While this draft represents the best efforts of the co-authors, and		While this draft represents the best efforts of the co-authors, and
	the working group, to be functionally complete, it is recognized		the working group, to be functionally complete, it is recognized that
	that extensions to DLEP will in all likelihood be necessary as more		extensions to DLEP will in all likelihood be necessary as more link
	link types are utilized. To allow for future innovation, the draft		types are utilized. To allow for future innovation, the draft
	allocates numbering space for experimental orders and sub-TLVs. DLEP		allocates numbering space for experimental implementations of both
	implementations MUST be capable of parsing and acting on the orders		signals and data items.
	and sub-TLVs as documented in this specification. DLEP orders/sub-TLVs
	in the experimental numbering range SHOULD be silently dropped by an
	implementation if they are not understood. The intent of the
	experimental numbering space is to allow for further development of
	DLEP protocol features and function. If subsequent development yields
	new features with sufficient applicability, those features should be
	either included in an update of this specification, or documented in
	a standalone specification.
	6. Normal Session Flow
	A session between a client and a server is established by exchanging
	the "Peer Discovery" and "Peer Offer" messages described below.
	The flows described in this document create a state-full protocol
	between client and server. Both client and server initialize in a
	"discovery" state, and the client issues a "Peer Discovery" message.
	When the server receives a Peer Discovery, it responds with a "Peer
	Offer" message, and enters an "in session" state with the client.
	Receipt of the Peer Offer at the client causes it (the client) to
	transition into the "in session" state.
	Once that exchange has successfully occurred, messages transferred
	in the context of the peer session will consist of
	o Periodic 'Heartbeat' messages, intended to keep the peer session
	alive, and to verify bidirectional connectivity, and/or
	o Peer Update messages, indicating some change in status that one
	of the peers needs to communicate to the other.
	In addition to the messages above, the peers will transmit DLEP
	messages concerning destinations in the network. These messages
	trigger creation/maintenance/termination of 'neighbor sessions'. For
	example, a peer will inform its DLEP partner of the presence of a
	new destination via the "Neighbor Up" message. Receipt of a Neighbor
	Up causes the receiving peer to allocate the necessary resources,
	creating a neighbor session, and transition to an "in session" state
	on the newly created neighbor session. The in-session state persists
	until notification of neighbor loss is received, or by optional
	timeout due to inactivity.
	The loss of a destination is communicated via the "Neighbor Down"		DLEP implementations MUST be capable of parsing and acting on the
	message, and changes in status to the destination (e.g. varying		mandatory signals and data items as documented in this specification.
	link quality, or addressing changes) are communicated via a		DLEP signals/data items that are optional, or are in the experimental
	"Neighbor Update" message.		numbering range SHOULD be silently dropped by an implementation if
			they are not understood.
	Again, metrics can be expressed within the context of a neighbor		The intent of the optional signals and data items, as well as the
	session via the Neighbor Update message, or within the context of		experimental numbering space, is to allow for further development of
	a peer session (reflecting the link as a whole) via the Peer Update		DLEP protocol features and function. Having experimental space
	message. In cases where metrics are provided on the peer session, the		reserved for both signals and data items gives maximum flexibility
	receiving peer MUST propagate the metrics to all neighbor sessions		for extending the protocol as conditions warrant. For example,
	accessed via the peer. A DLEP peer MAY send metrics both in a peer		experimental data items could be used by implementations to send
	session context (via the Peer Update message) and a neighbor session		additional metrics. A combination of experimental signals, and
	context (via Neighbor Update) at any time. The heuristics for		associated data items, could be used to implement new flow control
	applying received peer session and neighbor session metrics is left		schemes. If subsequent research and development define new features
	to implementations.		and function, then it should be standardized either as an update to
			this document, or as an additional stand-alone specification.
	In addition to receiving metrics about the link, DLEP provides for		6. Normal Session Flow
	the ability for a server to request a different amount of bandwidth,
	or latency, from the client via the Link Characteristics Message.
	This allows the server to deal with requisite increases (or decreases)
	of allocated bandwidth/latency in demand-based schemes in a more
	deterministic manner.
	7. Generic DLEP Packet Definition		At the start of a run, DLEP implementations (both router and modem)
			initialize the communications path. In a UDP implementation, this
			includes opening a socket and binding to the well-known port address
			(TBD). Once the communications path is established, an implementation
			would either, depending on configuration, proceed to periodically
			issue a "Peer Discovery" message. The Peer Discovery MAY be sent
			either via the multicast address allocated for DLEP (TBD), or via a
			unicast address, or drop into a "passive receive" mode, waiting on
			receipt of a Peer Discovery.
	The Generic DLEP Packet Definition follows the format for packets		Both modem and router initialize in a "discovery" state. Either the
	defined in [RFC5444].		modem, the router, or both, will then issue a "Peer Discovery"
			signal. The Peer Discovery signal MAY be issued to a unicast address
			(if a-priori knowledge of the address exists), or to the multicast
			address TBD.
	The Generic DLEP Packet Definition contains the following fields:		The receiver of a Peer Discovery message responds with a "Peer Offer"
			signal to indicate readiness to participate in the DLEP session. The
			receiver of a Peer Offer message responds with a "Peer Offer ACK"
			message, completing discovery. While the Peer Discovery message MAY
			be sent to the DLEP multicast address (TBD), the Peer Offer, and all
			subsequent traffic, is sent to the unicast address that originated
			the Peer Discovery. Once the Peer Offer signal is acknowledged, both
			participants (router and modem) transition to the "in session" state,
			creating a logical, stateful session between the modem and the
			router. Subsequent DLEP signals are then processed within the context
			of this router/modem session. DLEP partners use these signals to
			build their respective information bases regarding destinations that
			are accessible via the modem, and link characteristics associated
			with those destinations.
	0 1 2 3		The "in session" state created by the discovery signals is maintained
	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		until one of the following conditions occur:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Version| Flags | Packet Sequence Number | Packet TLV |
	| | | | Block... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message (Contains DLEP message)... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Version - Version of RFC 5444 specification on		o The session is explicitly terminated (using Peer Termination), or
	which the packet/messages/TLVs are		o The session times out, based on supplied timeout values.
	constructed.
	Flags - 4 bit field. All bits MUST be ignored		In order to maintain the session between router and modem, OPTIONAL
	by DLEP implementations.		periodic "Heartbeat" messages MAY be exchanged. These messages are
			intended to keep the session alive, and to verify bidirectional
			connectivity between the two participants. DLEP also provides for an
			OPTIONAL Peer Update message, intended to communicate some change in
			status (e.g., a change of layer 3 address parameters, or a modem-wide
			link change).
	Packet Sequence Number - If present, the packet sequence number		In addition to the messages above, the participants will transmit
	is parsed and ignored. DLEP does NOT		DLEP messages concerning destinations in the network. These messages
	use or generate packet sequence numbers.		trigger creation/maintenance/deletion of "neighbors" in the
			information base of the recipient. For example, a modem will inform
			its attached router of the presence of a new destination via the
			"Neighbor Up" signal. Receipt of a Neighbor Up causes the router to
			allocate the necessary resources, creating an entry in the
			information base with the specifics (e.g., MAC Address, Latency, Data
			Rate, etc) of the neighbor. The loss of a destination is communicated
			via the "Neighbor Down" signal, and changes in status to the
			destination (e.g. varying link quality, or addressing changes) are
			communicated via the "Neighbor Update" signal. The information on a
			given neighbor will persist in the router's information base until
			(1) a "Neighbor Down" is received, indicating that the modem has lost
			contact with the remote node, or (2) the router/modem session
			terminates, indicating that the router has lost contact with its own
			local modem.
	Packet TLV block - A TLV block which contains packet level		Again, metrics can be expressed within the context of a specific
	TLV information. DLEP implementations		neighbor via the Neighbor Update message, or on a modem-wide basis
	MUST NOT use this TLV block.		via the Peer Update message. In cases where metrics are provided on
			the router/modem session, the receiver MUST propagate the metrics to
			all neighbors in its information base that are accessed via the
			originator. A DLEP participant MAY send metrics both in a
			router/modem session context (via the Peer Update message) and a
			specific neighbor context (via Neighbor Update) at any time. The
			heuristics for applying received metrics is left to implementations.
	Message - The packet MAY contain zero or more		In addition to receiving metrics about the link, DLEP provides an
	messages, however, DLEP messages are		OPTIONAL signal allowing a router to request a different amount of
	encoded within an RFC 5444 Message		bandwidth, or latency, from the modem. This signal is referred to as
	TLV Block.		the Link Characteristics Message, and gives the router the ability to
			deal with requisite increases (or decreases) of allocated
			bandwidth/latency in demand-based schemes in a more deterministic
			manner.
	8. Message Header Format		7. Mandatory Signals and Data Items
	DLEP utilizes the following format for the RFC 5444 message header		The following DLEP signals are considered core to the specification;
			implementations MUST support these signals, and the associated data
			items, in order to be considered compliant:
	0 1 2 3		Signal Data Items
	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		====== ==========
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		Attached Peer Discovery Identification
	| Msg Type |Msg Flg|AddrLen| Message Size |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num | TLV Block... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - An 8-bit field which specifies the type		Peer Offer Identification
	of the message. For DLEP, this field
	contains DLEP_MESSAGE (value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is		Peer Offer ACK Status
	set). All other bits are unused and MUST
	be set to '0'.
	Message Address Length - A 4-bit unsigned integer field encoding the		Peer Termination Identification
	length of all addresses included in this
	message. DLEP implementations do not use
	this field; contents SHOULD be ignored.
	Message Size - A 16-bit unsigned integer field which		Peer Termination ACK Status
	specifies the number of octets that make up
	the message including the message header.
	Message Sequence Number - A 16-bit unsigned integer field that		Neighbor Up Identification
	contains a sequence number, generated by		MAC Address
	the originator of the message. Sequence		Maximum Data Rate
	numbers range from 1 to 65535. Sequence		Current Data Rate
	numbers roll over at 65535 to 1; 0 is		Latency
	invalid.		Resources
			Relative Link Quality
	TLV Block - TLV Block included in the message.		Neighbor Update Identification
			MAC Address
			Maximum Data Rate
			Current Data Rate
			Latency
			Resources
			Relative Link Quality
	9. Message TLV Block Format		Neighbor Down Identification
			MAC Address
	The DLEP protocol is organized as a set of orders, each with a		All other DLEP signals and data items are OPTIONAL. Implementations
	collection of Sub-TLVs. The Sub-TLVs carry information needed		MAY choose to provide them. Implementations that do not support
	to process and/or establish context (e.g. the MAC address of a		optional signals and data items SHOULD parse, and silently drop, all
	far-end router), and the 'tlv-type' field in the message TLV		unsupported signals and/or data items.
	block carries the DLEP order itself. The DLEP orders are
	enumerated in section 11.1 of this document, and the messages
	created using these orders are documented in sections 12 through
	27.
	DLEP uses the following settings for an RFC 5444 Message TLV		8. Generic DLEP Packet Definition
	block:
	0 1 2 3		The Generic DLEP Packet consists of a sequence of TLVs. The first TLV
	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		represents the signal being communicated (e.g., a "Neighbor Up", or a
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		"Peer Offer"). Subsequent TLVs contain the data items pertinent to
	| TLVs Length | TLV Type | TLV Flags |		the signal (e.g., Maximum Data Rate, or Latency, etc).
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Value... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLVs Length - A 16-bit unsigned integer field that contains the total		The Generic DLEP Packet Definition contains the following fields:
	number of octets in all of the immediately following
	TLV elements (tlvs-length not included).
	TLV Type - An 8-bit unsigned integer field specifying the type		0 1 2 3
	of the TLV. DLEP uses this field to specify the DLEP		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
	order. Valid DLEP orders are defined in section 11.1		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	of this document.		|Signal TLV Type | Length | DLEP data items... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - An 8-bit flags bit field. Bit 3 (thasvalue) MUST be		Signal - One of the DLEP Signal TLV type values
	set; all other bits are not used and MUST be set		defined in this document.
	to '0'.
	Length - Length of the 'Value' field of the TLV		Length - The length of all of the DLEP data items
			associated with this signal.
	Value - A field of length <Length> which contains data		DLEP data items - One or more data items, encoded in TLVs,
	specific to a particular TLV type. In the DLEP		as defined in this document.
	case, this field will consist of a collection of
	DLEP sub-TLVs appropriate for the DLEP action
	specified in the TLV type field.
	10. DLEP sub-TLVs		9. DLEP Data Items
	DLEP protocol messages are transported in an RFC 5444 message TLV.		As mentioned earlier, DLEP protocol messages are transported as a
	All DLEP messages use the RFC 5444 DLEP_MESSAGE value (TBD). The		collection of TLVs. The first TLV present in a DLEP message MUST be
	protocol messages consist of a DLEP order, encoded in the 'tlv-type'		one of the Signal TLVs, documented in section [INSERT REFERENCE
	field in the message TLV block, with the 'value' field of the TLV		HERE]. The signals are followed by one or more data items, indicating
	block containing a collection (1 or more) DLEP sub-TLVs.		the specific changes that need to be instantiated in the receiver's
			information base.
	The format of DLEP Sub-TLVs is consistent with RFC 5444 in that the		Valid DLEP Data Items are:
	Sub-TLVs contain a flag field in addition to the type, length, and
	value fields. Valid DLEP Sub-TLVs are:
	TLV TLV		TLV TLV
	Value Description		Value Description
	=========================================		=========================================
	TBD Identification sub-TLV		TBD Identification
	TBD DLEP Version sub-TLV		TBD DLEP Version
	TBD Peer Type sub-TLV		TBD Peer Type
	TBD MAC Address sub-TLV		TBD IPv4 Address
	TBD IPv4 Address sub-TLV		TBD IPv6 Address
	TBD IPv6 Address sub-TLV		TBD Maximum Data Rate (MDR)
	TBD Maximum Data Rate (MDR) sub-TLV		TBD Current Data Rate (CDR)
	TBD Current Data Rate (CDR) sub-TLV		TBD Latency
	TBD Latency sub-TLV		TBD Resources
	TBD Resources sub-TLV		TBD Expected Forwarding Time (EFT)
	TBD Expected Forwarding Time (ETX) sub-TLV		TBD Relative Link Quality (RLQ)
	TBD Relative Link Quality (RLQ) sub-TLV		TBD Status
	TBD Status sub-TLV		TBD Heartbeat Interval/Threshold
	TBD Heartbeat Interval sub-TLV		TBD Neighbor down ACK timer
	TBD Heartbeat Threshold sub-TLV		TBD Link Characteristics ACK timer
	TBD Neighbor down ACK timer sub-TLV		TBD Credit Window Status
	TBD Link Characteristics ACK timer sub-TLV		TBD Credit Grant
	TBD Credit Window Status sub-TLV		TBD Credit Request
	TBD Credit Grant sub-TLV
	TBD Credit Request sub-TLV
	DLEP sub-TLVs contain the following fields:
	0 1 2 3		DLEP data item TLVs contain the following fields:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV Type |TLV Flags=0x10 | Length | Value... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - An 8-bit unsigned integer field specifying the type		0 1 2 3
	of the sub-TLV.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| TLV Type | Length | Value... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - An 8-bit flags bit field. Bit 3 (thasvalue) MUST be		TLV Type - An 8-bit unsigned integer field specifying the data
	set, all other bits are not used and MUST be set to		item being sent.
	'0'.
	Length - An 8-bit length of the value field of the sub-TLV		Length - An 8-bit length of the value field of the data item
	Value - A field of length <Length> which contains data		Value - A field of length <Length> which contains data
	specific to a particular sub-TLV.		specific to a particular data item.
	10.1 Identification Sub-TLV		9.1 Identification
	This Sub-TLV MUST exist in the TLV Block for all DLEP messages, and		This data item MUST exist in all DLEP messages, and MUST be the first
	MUST be the first Sub-TLV of the message. Further, there MUST be ONLY		data item of the message (e.g., it MUST immediately follow the signal
	one Identification Sub-TLV in an RFC 5444 message TLV block. The		TLV). Further, there MUST be ONLY one Identification data item in a
	Identification sub-TLV contains client and server identification		DLEP message. The data item contains identification information used
	information used to establish the proper context for processing DLEP		to establish the proper context (e.g., the router/modem session) for
	protocol messages.		processing DLEP protocol messages.
	The Identification sub-TLV contains the following fields:		The format of the Identification Data Item is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type = TBD |TLV Flags=0x10 |Length = 8 | Server ID |		|TLV Type = TBD | Length = 8 | Router ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Server ID | Client ID |		| Router ID | Modem ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Client ID |		| Modem ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - Value TBD		TLV Type - Value TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are
	unused and MUST be set to '0'.
	Length - 8		Length - 8
	Server ID - Indicates the Server ID of the DLEP session.		Router ID - Indicates the Router ID of the DLEP session.
	Client ID - indicates the Client ID of the DLEP session.		Modem ID - indicates the Modem ID of the DLEP session.
	When the client initiates discovery (via the Peer Discovery message),		During transmission of a DLEP Peer Discovery signal, the transmitter
	it MUST set the Client ID to a 32-bit quantity that will be used to		MUST set its ID to a 32-bit quantity that will be used to uniquely
	uniquely identify this session from the client-side. The client MUST		identify this session from the transmitter's perspective. The other
	set the Server ID to '0'. When responding to the Peer Discovery		ID value MUST be set the to '0'. When responding to the Peer
	message, the server MUST echo the Client ID, and MUST supply its own		Discovery signal (via the Peer Offer signal), the transmitter MUST
	unique 32-bit quantity to identify the session from the server's		echo any received ID value, and MUST supply its own unique 32-bit
	perspective. After the Peer Discovery/Peer Offer exchange, both the		quantity to identify the session from its perspective. After the Peer
	Client ID and the Server ID MUST be set to the values obtained from		Discovery/Peer Offer exchange, subsequent signals on this DLEP
	the Peer DIscovery/Peer Offer sequence.		session MUST contain the ID values obtained from the Peer
			Discovery/Peer Offer sequence.
	10.2 DLEP Version Sub-TLV		9.2 DLEP Version
	The DLEP Version Sub-TLV is an OPTIONAL TLV in both the Peer		The DLEP Version TLV is an OPTIONAL TLV in both the Peer Discovery
	Discovery and Peer Offer messages. The Version Sub-TLV is used to		and Peer Offer messages. The Version TLV is used to indicate the
	indicate the client or server version of the protocol. The client		version of the protocol running in the originator. A participant MAY
	and server MAY use this information to decide if the peer is running		use this information to decide if the potential session partner is
	at a supported level.		running at a supported level.
	The DLEP Version Sub-TLV contains the following fields:		The DLEP Version TLV contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length=4 | Major Version |		|TLV Type =TBD |Length=4 | Major Version |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Major Version | Minor Version |		| Minor Version |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are
	not used and MUST be set to '0'.
	Length - Length is 4		Length - Length is 4
	Major Version - Major version of the client or router protocol.		Major Version - Major version of the modem or router protocol.
	Minor Version - Minor version of the client or router protocol.		Minor Version - Minor version of the modem or router protocol.
	Support of this draft is indicated by setting the Major Version		Support of this draft is indicated by setting the Major Version
	to '1', and the Minor Version to '2' (e.g. Version 1.2).		to '1', and the Minor Version to '3' (e.g. Version 1.3).
	10.3 Peer Type Sub-TLV		9.3 Peer Type
	The Peer Type Sub-TLV is used by the server and client to give		The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and
	additional information as to its type. It is an OPTIONAL sub-TLV in		Peer Offer messages. The Peer Type TLV is used by the router and
	both the Peer Discovery Message and the Peer Offer message. The peer		modem to give additional information as to its type. The peer type is
	type is a string and is envisioned to be used for informational		a string and is envisioned to be used for informational purposes
	purposes (e.g. as output in a display command).		(e.g. as output in a display command).
	The Peer Type sub-TLV contains the following fields:		The Peer Type TLV contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length= peer |Peer Type Str |		|TLV Type =TBD |Length= peer |Peer Type String |
	| | |type string len|Max Len = 80 |		| |type string len|Max Len = 80 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits		Length - Length of peer type string (80 octets maximum).
	are not used and MUST be set to '0'.
	Length - Length of peer type string (80 bytes maximum).
	Peer Type String - Non-Null terminated peer type string, maximum		Peer Type String - Non-Null terminated string, maximum length of 80
	length of 80 bytes. For example, a satellite		octets. For example, a satellite modem might set
	modem might set this variable to 'Satellite		this variable to 'Satellite terminal'.
	terminal'.
	10.4 MAC Address Sub-TLV		9.4 MAC Address
	The MAC address Sub-TLV MUST appear in all neighbor-oriented		The MAC address TLV MUST appear in all neighbor-oriented signals
	messages (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor		(e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK,
	Down ACK, Neighbor Update, Link Characteristics Request, and Link		Neighbor Update, Link Characteristics Request, and Link
	Characteristics ACK). The MAC Address sub-TLV contains the address		Characteristics ACK). The MAC Address TLV contains the address of the
	of the far-end (neighbor) destination, and may be either a physical		destination on the remote node. The MAC address MAY be either a
	or a virtual destination. Examples of a virtual destination would		physical or a virtual destination. Examples of a virtual destination
	be a multicast MAC address, or the broadcast MAC (0xFFFFFFFFFFFF).		would be a multicast MAC address, or the broadcast MAC
			(0xFFFFFFFFFFFF).
	The MAC Address sub-TLV contains the following fields:		0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	0 1 2 3		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		|TLV Type =TBD |Length = 6 | MAC Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 6 |MAC Address |		| MAC Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MAC Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MAC Address |
	+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not
	used and MUST be set to '0'.
	Length - 6		Length - 6
	MAC Address - MAC Address of the destination (either physical or		MAC Address - MAC Address of the destination (either physical or
	virtual).		virtual).
	10.5 IPv4 Address Sub-TLV		9.5 IPv4 Address
	The IPv4 Address Sub-TLV MAY be used in Neighbor Up, Neighbor		The IPv4 Address TLV is an OPTIONAL TLV. If supported, it MAY appear
	Update, and Peer Update Messages, if the client is aware of the		in Neighbor Up, Neighbor Update, and Peer Update messages. When
	Layer 3 address. When included in Neighbor messages, the IPv4		included in Neighbor messages, the IPv4 Address TLV contains the IPv4
	Address sub-TLV contains the IPv4 address of the far-end neighbor.		address of the neighbor, as well as a subnet mask value. In the Peer
	In the Peer Update message, it contains the IPv4 address of the		Update message, it contains the IPv4 address of the originator of the
	sending peer. In either case, the sub-TLV also contains an		message. In either case, the TLV also contains an indication of
	indication of whether this is a new or existing address, or is a		whether this is a new or existing address, or is a deletion of a
	deletion of a previously known address.		previously known address.
	The IPv4 Address Sub-TLV contains the following fields:		The IPv4 Address TLV contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 5 | Add/Drop |		|TLV Type =TBD |Length = 6 | Add/Drop | IPv4 Address |
	| | | | Indicator |		| | | Indicator |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Address |		| IPv4 Address | Subnet Mask |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not		Length - 6
	used and MUST be set to '0'.
	Length - 5
	Add/Drop - Value indicating whether this is a new or existing		Add/Drop - Value indicating whether this is a new or existing
	Indicator address (0x01), or a withdrawal of an address (0x02).		IPv4 address
	IPv4 Address - IPv4 Address of the far-end neighbor or peer.		IPv4 Address - The IPv4 address of the neighbor or peer.
	10.6 IPv6 Address Sub-TLV		Subnet Mask - A subnet mask (0-32) to be applied to the IPv4
			address.
	The IPv6 Address Sub-TLV MAY be used in Neighbor Up, Neighbor		9.6 IPv6 Address
	Update, and Peer Update Messages, if the client is aware of the
	Layer 3 address. When included in Neighbor messages, the IPv6
	Address sub-TLV contains the IPv6 address of the far-end neighbor.
	In the Peer Update, it contains the IPv6 address of the
	originating peer. In either case, the sub-TLV also contains an
	indication of whether this is a new or existing address, or is a
	deletion of a previously known address.
	The IPv6 Address sub-TLV contains the following fields:		The IPv6 Address TLV is an OPTIONAL TLV. If supported, it MAY be used
			in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update
			Messages. When included in Neighbor messages, this data item contains
			the IPv6 address of the neighbor. In the Peer Discovery and Peer
			Update, it contains the IPv6 address of the originating peer. In
			either case, the data item also contains an indication of whether
			this is a new or existing address, or is a deletion of a previously
			known address, as well as a subnet mask.
	0 1 2 3		The IPv6 Address TLV contains the following fields:
	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
	|TLV Type =TBD |TLV Flags=0x10 |Length = 17 | Add/Drop |		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
	| | | | Indicator |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		|TLV Type =TBD |Length = 18 | Add/Drop | IPv6 Address |
	| IPv6 Address |		| | | Indicator | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address |		| IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address |		| IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address |		| IPv6 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6 Address | Subnet Mask |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not		Length - 18
	used and MUST be set to '0'.
	Length - 17		Add/Drop - Value indicating whether this is a new or existing
			address (0x01), or a withdrawal of an address (0x02).
	Add/Drop - Value indicating whether this is a new or		IPv6 Address - IPv6 Address of the neighbor or peer.
	Indicator existing address (0x01), or a withdrawal of
	an address (0x02).
	IPv6 Address - IPv6 Address of the far-end neighbor or peer.		Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6
			address.
	10.7 Maximum Data Rate Sub-TLV		9.7 Maximum Data Rate
	The Maximum Data Rate (MDR) Sub-TLV is used in Neighbor Up, Neighbor		The Maximum Data Rate (MDR) TLV is used in Neighbor Up, Neighbor
	Update, Peer Discovery, Peer Update, and Link Characteristics ACK		Update, Peer Discovery, Peer Update, and Link Characteristics ACK
	Messages to indicate the maximum theoretical data rate, in bits per		Messages to indicate the maximum theoretical data rate, in bits per
	second, that can be achieved on the link. When metrics are reported		second, that can be achieved on the link. When metrics are reported
	via the messages listed above, the maximum data rate MUST be reported.		via the messages listed above, the maximum data rate MUST be
			reported.
	The Maximum Data Rate sub-TLV contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 8 | MDR (bps) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MDR (bps) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MDR (bps) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 8 | MDR (bps) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MDR (bps) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MDR (bps) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other		TLV Type - TBD
	bits are not used and MUST be set to '0'.
	Length - 8		Length - 8
	Maximum Data Rate - A 64-bit unsigned number, representing the		Maximum Data Rate - A 64-bit unsigned number, representing the
	maximum theoretical data rate, in bits per		maximum theoretical data rate, in bits per
	second (bps), that can be achieved on the		second (bps), that can be achieved on the link.
	link.
	10.8 Current Data Rate Sub-TLV		9.8 Current Data Rate
	The Current Data Rate (CDR) Sub-TLV is used in Neighbor Up, Neighbor		The Current Data Rate (CDR) TLV is used in Neighbor Up, Neighbor
	Update, Peer Discovery, Peer Update, Link Characteristics Request,		Update, Peer Discovery, Peer Update, Link Characteristics Request,
	and Link Characteristics ACK messages to indicate the rate at which		and Link Characteristics ACK messages to indicate the rate at which
	the link is currently operating, or in the case of the Link		the link is currently operating, or in the case of the Link
	Characteristics Request, the desired data rate for the link.		Characteristics Request, the desired data rate for the link. When
			metrics are reported via the messages above, the current data rate
	The Current Data Rate sub-TLV contains the following fields:		MUST be reported.
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDR (bps) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CDR (bps) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CDR (bps) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		The Current Data Rate TLV contains the following fields:
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other		0 1 2 3
	bits are not used and MUST be set to '0'.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDR (bps) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| CDR (bps) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| CDR (bps) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Length - 8		TLV Type - TBD
	Current Data Rate - A 64-bit unsigned number, representing the		Length - 8
	current rate, in bits per second (bps),
	on the link. When reporting metrics (e.g,
	in Neighbor Up, Neighbor Down, Peer
	Discovery, Peer Update, or Link
	Characteristics ACK), if there is no
	distinction between current and maximum
	data rates, current data rate SHOULD be
	set equal to the maximum data rate.
	10.9 Expected Forwarding Time Sub-TLV		Current Data Rate - A 64-bit unsigned number, representing the
			current data rate, in bits per second, that is
			currently be achieved on the link, or the
			desired data rate in bits per second in the Link
			Characteristics Request message. If there is no
			distinction between current and maximum data
			rates, current data rate MUST be set equal to
			the maximum data rate.
	The Expected Forwarding Time (EFT) Sub-TLV is used in Neighbor Up,		9.9 Expected Forwarding Time
	Neighbor Update, Peer Discovery, and Peer Update messages to indicate
	the typical latency between the arrival of a given packet at the
	transmitting device and the reception of the packet at the other end
	of the link. EFT combines transmission time, idle time, waiting time,
	freezing time, and queuing time to the degree that those values are
	meaningful to a given transmission medium.
	The Expected Forwarding Time sub-TLV contains the following fields:		The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item.
			If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer
			Discovery, and Peer Update messages to indicate the typical latency
			between the arrival of a given packet at the transmitting device and
			the reception of the packet at the other end of the link. EFT
			combines transmission time, idle time, waiting time, freezing time,
			and queuing time to the degree that those values are meaningful to a
			given transmission medium.
	0 1 2 3		The Expected Forwarding Time TLV contains the following fields:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 4 | EFT (ms) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| EFT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 4 | EFT (ms) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| EFT (ms) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other		TLV Type - TBD
	bits are not used and MUST be set to '0'.
	Length - 4		Length - 4
	Current Data Rate - A 32-bit unsigned number, representing the		EFT - A 32-bit unsigned number, representing the expected
	expected forwarding time, in milliseconds,		forwarding time, in milliseconds, on the link.
	on the link.
	10.10 Latency Sub-TLV		9.10 Latency
	The Latency Sub-TLV is used in Neighbor Up, Neighbor Update, Peer		The Latency TLV is used in Neighbor Up, Neighbor Update, Peer
	Discovery, Peer Update, Link Characteristics Request, and Link		Discovery, Peer Update, Link Characteristics Request, and Link
	Characteristics ACK messages to indicate the amount of latency on		Characteristics ACK messages to indicate the amount of latency on the
	the link, or in the case of the Link Characteristics Request, to		link, or in the case of the Link Characteristics Request, to indicate
	indicate the maximum latency required (e.g. a should-not-exeed value)		the maximum latency required on the link. When metrics are reported
	on the link.		via the messages above, Latency MUST be reported.
	The Latency Sub-TLV contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 2 |Latency (ms) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Latency (ms) |
	+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 2 | Latency (ms) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other		TLV Type - TBD
	bits are not used and MUST be set to '0'.
	Length - 2		Length - 2
	Latency - The transmission delay that a packet		Latency - A 16-bit unsigned value, representing the transmission
	encounters as it is transmitted over the		delay that a packet encounters as it is transmitted
	link. In Neighbor Up, Neighbor Update,		over the link. In Neighbor Up, Neighbor Update, and
	and Link Characteristics ACK, this value		Link Characteristics ACK, this value is reported as
	is reported in absolute delay, in		delay, in milliseconds. The calculation of latency is
	milliseconds. The calculation of latency		implementation dependent. For example, the latency may
	is implementation dependent. For example,		be a running average calculated from the internal
	the latency may be a running average		queuing. If a device cannot calculate latency, it MUST
	calculated from the internal queuing. If		be reported as 0. In the Link Characteristics Request
	a device cannot calculate latency, it		Message, this value represents the maximum delay, in
	SHOULD be reported as 0. In the Link		milliseconds, expected on the link.
	Characteristics Request Message, this value
	represents the maximum delay, in
	milliseconds, expected on the link.
	10.11 Resources Sub-TLV		9.11 Resources
	The Resources Sub-TLV is used in Neighbor Up, Neighbor Update, Peer		The Resources TLV is used in Neighbor Up, Neighbor Update, Peer
	Discovery, Peer Update, and Link Characteristics ACK messages to		Discovery, Peer Update, and Link Characteristics ACK messages to
	indicate a percentage (0-100) amount of resources (e.g. battery		indicate a percentage (0-100) amount of resources (e.g. battery
	power) remaining on the originating peer.		power) remaining on the originating peer. If metrics are reported,
			via the above messages, Resources MUST be reported.
	The Resources TLV contains the following fields:		The Resources TLV contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Resources |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 1 | Resources |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other		TLV Type - TBD
	bits are not used and MUST be set to '0'.
	Length - 1		Length - 1
	Resources - A percentage, 0-100, representing the
	amount of remaining resources, such as
	battery power. If resources cannot be
	calculated, a value of 100 SHOULD be
	reported.
	10.12 Relative Link Quality Sub-TLV		Resources - A percentage, 0-100, representing the amount of
			remaining resources, such as battery power. If
			resources cannot be calculated, a value of 100 MUST be
			reported.
	The Relative Link Quality (RLQ) Sub-TLV is used in Neighbor Up,		9.12 Relative Link Quality
	Neighbor Update, Peer Discovery, Peer Update, and Link
	Characteristics ACK messages to indicate the quality of the link
	as calculated by the originating peer.
	The Relative Link Quality sub-TLV contains the following fields:		The Relative Link Quality (RLQ) TLV is used in Neighbor Up, Neighbor
			Update, Peer Discovery, Peer Update, and Link Characteristics ACK
			messages to indicate the quality of the link as calculated by the
			originating peer. If metrics are reported via the above messages, RLQ
			MUST be reported.
	0 1 2 3		The Relative Link Quality TLV contains the following fields:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 1 |Relative Link |
	| | | |Quality (RLQ) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 1 |Relative Link |
			| | |Quality (RLQ) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other		TLV Type - TBD
	bits are not used and MUST be set to '0'.
	Length - 1		Length - 1
	Relative Link Quality - A non-dimensional number, 0-100,		Relative Link Quality - A non-dimensional number, 0-100,
	representing relative link quality. A value		representing relative link quality. A value of
	of 100 represents a link of the highest		100 represents a link of the highest quality.
	quality. If the RLQ cannot be calculated, a		If the RLQ cannot be calculated, a value of
	value of 100 SHOULD be reported.		100 MUST be reported.
	10.13 Status Sub-TLV		9.13 Status
	The Status Sub-TLV is sent from either the client or server to		The Status TLV is an OPTIONAL TLV. It is sent as part of an
	indicate the success or failure of a given request		acknowledgement message, from either the modem or the router, to
			indicate the success or failure of a given request.
	The Status Sub-TLV contains the following fields:		The Status TLV contains the following fields:
	0 1 2 3		0 1 2
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Code |		|TLV Type =TBD |Length = 1 | Code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits
	are not used and MUST be set to '0'.
	Length - 1		Length - 1
	Termination Code - 0 = Success		Termination Code - 0 = Success, Non-zero = Failure. Specific values
	Non-zero = Failure. Specific values of a non-		of a non-zero termination code depend on the
	zero termination code depend on the operation		operation requested (e.g. Neighbor Up,
	requested (e.g. Neighbor Up, Neighbor Down, etc).		Neighbor Down, etc).
	10.14 Heartbeat Interval Sub-TLV		9.14 Heartbeat Interval/Threshold
	The Heartbeat Interval Sub-TLV MAY be sent from the client during		The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. If
	Peer Discovery to indicate the desired Heartbeat timeout window.		supported, it MAY be sent during Peer Discovery to indicate the
	If included in the Peer Discovery, the server MUST either accept the		desired Heartbeat timeout window. If the modem includes the Heartbeat
	timeout interval, or reject the Peer Discovery. Failing to include		Interval TLV in Peer Discovery, the router MUST either accept the
	the Heartbeat Interval Sub-TLV in Peer Discovery indicates a		timeout interval supplied by the modem, or reject the Peer Discovery.
	desire to establish the peer-to-peer DLEP session without an		Peer Discovery messages that do not include the Heartbeat Interval
	activity timeout (e.g. an infinite timeout value).		TLV in Peer Discovery indicates a desire to establish the
			router/modem session without an activity timeout (e.g. an infinite
			timeout value). If an activity timeout is supported, implementations
			MAY choose to implement heuristics such that signals sent/received
			reset the timer window.
	The Heartbeat Interval Sub-TLV contains the following fields:		The Interval is used to specify a period (in seconds) for Heartbeat
			Messages (See Section 23). The Threshold value is used to indicate
			the desired number of windows, each of time (Heartbeat Interval)
			seconds, to wait before either participant declares the router/modem
			session lost. In this case, the overall amount of time before a
			router/modem is declared lost is expressed as (Interval * Threshold).
			Specifying an Interval value of 0 indicates the desire to disable
			Heartbeat messages entirely (e.g., the Interval is set to an infinite
			value). Setting the Threshold value to 0 is undefined, and TLVs with
			a Threshold value of 0 MUST be rejected by the recipient.
	0 1 2 3		The Heartbeat Interval/Threshold TLV contains the following fields:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 1 | Interval | Threshold |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are		TLV Type - TBD
	not used and MUST be set to '0'.
	Length - 1		Length - 1
	Interval - 0 = Do NOT use heartbeats on this peer-to-peer		Interval - 0 = Do NOT use heartbeats on this peer-to-peer
	session. Non-zero = Interval, in seconds, for		session. Non-zero = Interval, in seconds, for
	heartbeat messages.		heartbeat messages.
	10.15 Heartbeat Threshold Sub-TLV		Threshold - Number of windows, of Heartbeat Interval seconds,
			to wait before declaring a peer-to-peer session to
	The Heartbeat Threshold Sub-TLV MAY be sent from the client during		be lost.
	Peer Discovery to indicate the desired number of windows, of time
	(Heartbeat Interval) seconds, to wait before either peer declares
	the peer session lost. In this case, the overall amount of time
	before a peer session is declared lost is expressed as
	(Interval * Threshold), where 'Interval' is the value in the
	Heartbeat Interval sub-TLV, documented above. If this sub-TLV is
	included by the client in the Peer Discovery, the client MUST also
	specify the Heartbeat Interval sub-TLV with a non-zero interval. If
	this sub-TLV is received during Peer Discovery, the server MUST
	either accept the threshold, or reject the Peer Discovery. If the
	Heartbeat Interval Sub-TLV is included, but this Sub-TLV is
	omitted, then a threshold of '1' is assumed.
	The Heartbeat Threshold Sub-TLV contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Threshold |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are
	not used and MUST be set to '0'.
	Length - 1
	Threshold - 0 = Do NOT use heartbeats on this peer-to-peer
	session. Non-zero = Number of windows, of
	Heartbeat Interval seconds, to wait before
	declaring a peer-to-peer session to be lost.
	10.16 Link Characteristics ACK Timer Sub-TLV
	The Link Characteristic ACK Timer Sub-TLV MAY be sent from the		9.15 Link Characteristics ACK Timer
	client during Peer Discovery to indicate the desired number of
	seconds the server should wait for a response to a Link
	Characteristics Request. If this sub-TLV is received during Peer
	Discovery, the server MUST either accept the timeout value, or
	reject the Peer Discovery. If this Sub-TLV is omitted,
	implementations SHOULD choose a default value.
	The Link Characteristics ACK Timer Sub-TLV contains the		The Link Characteristics ACK Timer TLV is an OPTIONAL TLV. If
	following fields:		supported, it MAY be sent during Peer Discovery to indicate the
			desired number of seconds to wait for a response to a Link
			Characteristics Request. If a router receives this TLV from a modem
			during Peer Discovery, the router MUST either accept the timeout
			value, or reject the Peer Discovery. If this TLV is omitted,
			implementations supporting the Link Characteristics Request SHOULD
			choose a default value.
	0 1 2 3		The Link Characteristics ACK Timer TLV contains the following fields:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		0 1 2
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|TLV Type =TBD |Length = 1 | Interval |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are		TLV Type - TBD
	not used and MUST be set to '0'.
	Length - 1		Length - 1
	Interval - 0 = Do NOT use timeouts for Link Characteristics		Interval - 0 = Do NOT use timeouts for Link Characteristics
	requests on this peer-to-peer session.		requests on this router/modem session. Non-zero =
	Non-zero = Interval, in seconds, to wait before		Interval, in seconds, to wait before considering a
	considering a Link Characteristics Request has		Link Characteristics Request has been lost.
	been lost.
	10.17 Credit Window Status Sub-TLV		9.16 Credit Window Status
	The Credit Window Status Sub-TLV MUST be sent by the DLEP peer		The Credit Window Status TLV is an OPTIONAL TLV. If credits are
	originating a Neighbor Up message when use of credits is desired		supported by the DLEP participants (both the router and the modem),
	for a given session. In the Neighbor Up message, when credits		the Credit Window Status TLV MUST be sent by the participant
	are desired, the originating peer MUST set the value of the		receiving a Credit Grant Request for a given neighbor.
	window it controls (e.g. the Client Receive Window, or Server
	Receive Window) to an initial, non-zero value. The peer receiving
	a Neighbor Up message with a Credit Window Status Sub-TLV MUST
	either reject the use of credits, via a Neighbor Up ACK response
	with the correct Status Sub-TLV, or set the initial value from
	the data contained in the Credit Window Status Sub-TLV. If the
	initialization completes successfully, the receiving peer MUST
	respond to the Neighbor Up message with a Neighbor Up ACK message
	that contains a Credit Window Status Sub-TLV, initializing its
	receive window.
	The Credit Window Status Sub-TLV contains the following fields:		The Credit Window Status TLV contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 16 | Client Receive|		|TLV Type =TBD |Length = 16 | Modem Receive Window Value |
	| | | | Window value |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Modem Receive Window Value |
	| Client Receive Window Value |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Modem Receive Window Value | Router Receive Window Value |
	| Client Receive Window Value | Server Receive|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Window Value |		| Router Receive Window Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Server Receive Window Value |		| Router Receive Window Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Server Receive Window Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits		Length - 16
	are not used and MUST be set to '0'.
	Length - 16		Modem Receive Window Value - A 64-bit unsigned number, indicating
			the current (or initial) number of
			credits available on the Modem Receive
			Window.
	Client Receive - A 64-bit unsigned number, indicating the		Router Receive Window Value - A 64-bit unsigned number, indicating
	Window value current (or initial) number of credits		the current (or initial) number of
	available on the Client Receive Window.		credits available on the Router Receive
			Window.
	Server Receive - A 64-bit unsigned number, indicating the		9.17 Credit Grant Request
	Window Value current (or initial) number of credits
	available on the Server Receive Window.
	10.18 Credit Grant Sub-TLV		The Credit Grant Request TLV is an OPTIONAL TLV. If credits are
			supported, the Credit Grant Request TLV is sent from a DLEP
			participant to grant an increment to credits on a window. The Credit
			Grant TLV is sent as a data item in either the Neighbor Up or
			Neighbor Update messages. The value in a Credit Grant TLV represents
			an increment to be added to any existing credits available on the
			window. Upon successful receipt and processing of a Credit Grant TLV,
			the receiver MUST respond with a message containing a Credit Window
			Status TLV to report the updated aggregate values for synchronization
			purposes.
	The Credit Grant Request Sub-TLV MAY be sent from either DLEP		In the Neighbor Up message, when credits are desired, the originating
	peer to grant an increment to credits on a window. The Credit		peer MUST set the initial credit value of the window it controls
	Grant Sub-TLV is sent as part of a Neighbor Update message. The		(e.g. the Modem Receive Window, or Router Receive Window) to an
	value in a Credit Grant Sub-TLV represents an increment to be		initial, non-zero value. If the receiver of a Neighbor Up message
	added to any existing credits available on the window. Upon		with a Credit Grant Request TLV supports credits, the receiver MUST
	successful receipt and processing of a Credit Grant Sub-TLV, the		either reject the use of credits, via a Neighbor Up ACK response with
	receiving peer SHOULD respond with a DLEP Neighbor Update message		the correct Status TLV, or set the initial value from the data
	containing a Credit Window Status Sub-TLV to report the updated		contained in the Credit Window Status TLV. If the initialization
	aggregate values for synchronization purposes.		completes successfully, the receiver MUST respond to the Neighbor Up
			message with a Neighbor Up ACK message that contains a Credit Window
			Status TLV, initializing its receive window.
	The Credit Grant Sub-TLV contains the following fields:		The Credit Grant TLV contains the following fields:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 8 | Credit |		|TLV Type =TBD |Length = 8 | Credit Increment |
	| | | | Increment |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Credit Increment |
	| Credit Increment |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| Credit Increment |
	| Credit Increment |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits		Length - 8
	are not used and MUST be set to '0'.
	Length - 0
	Reserved - A 64-bit unsigned number representing the		Reserved - A 64-bit unsigned number representing the
	additional credits to be assigned to the		additional credits to be assigned to the credit
	credit window. Since credits can only be		window. Since credits can only be granted by the
	granted by the receiver on a window, the		receiver on a window, the applicable credit window
	applicable credit window (either the CRW or		(either the MRW or the RRW) is derived from the
	the SRW) is derived from the sender of the		sender of the grant. The Credit Increment MUST NOT
	grant. The Credit Increment MUST NOT cause		cause the window to overflow; if this condition
	the window to overflow; if this condition		occurs, implementations MUST set the credit window
	occurs, implementations MUST set the credit		to the maximum value contained in a 64-bit
	window to the maximum value contained in a		quantity.
	64-bit quantity.
	10.19 Credit Request Sub-TLV		9.18 Credit Request
	The Credit Request Sub-TLV MAY be sent from either DLEP peer, via		The Credit Request TLV is an OPTIONAL TLV. If credits are supported,
	a Neighbor Update order, to indicate the desire for the partner to		the Credit Request TLV MAY be sent from either DLEP participant, via
	grant additional credits in order for data transfer to proceed on		a Neighbor Update signal, to indicate the desire for the partner to
	the session. If the corresponding Neighbor Up message for this		grant additional credits in order for data transfer to proceed on the
	session did NOT contain a Credit Window Status Sub-TLV, indicating		session. If the corresponding Neighbor Up message for this session
	that credits are to be used on the session, then the Credit Request		did NOT contain a Credit Window Status TLV, indicating that credits
	Sub-TLV MUST be rejected, by sending a Neighbor Update ACK containing		are to be used on the session, then the Credit Request TLV MUST be
	a Status Sub-TLV, by the receiving peer. If credits are in use on		rejected by the receiver via a Neighbor Update ACK message.
	the session, then the receiving peer MAY respond with a DLEP
	Neighbor Update message containing a Credit Grant Sub-TLV with
	an increment of credits for the session.
	The Credit Request Sub-TLV contains the following fields:		The Credit Request TLV contains the following fields:
	0 1 2 3		0 1 2
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type =TBD |TLV Flags=0x10 |Length = 0 | Reserved, MUST|		|TLV Type =TBD |Length = 0 | Reserved, MUST|
	| | | | be set to 0 |		| | | be set to 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Type - TBD		TLV Type - TBD
	TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits		Length - 0
	are not used and MUST be set to '0'.
	Length - 0		Reserved - This field is currently unused and MUST be set to 0.
	Reserved - 0 = This field is currently unused and MUST be		10. DLEP Protocol Messages
	set to 0.
	11. DLEP Protocol Messages		DLEP messages are encoded as a string of Type-Length-Value (TLV)
			constructs. The first TLV in a DLEP message MUST be a valid DLEP
			signal, as defined in section 11.1 of this document. The second TLV
			MUST be the Identification data item, defined in section 10.1
			Following those two TLVs are 0 or more TLVs, representing the data
			items that are appropriate for the signal. The layout of a DLEP
			message is thus:
	DLEP places no additional requirements on the RFC 5444 Packet		0 1 2 3
	formats, or the packet header. DLEP does require that the optional		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
	'msg-seq-num' in the message header exist, and defines a set of		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	values for the 'tlv-type' field in the RFC 5444 TLV block. Therefore,		| DLEP Signal |DLEP Message |Identification |Identification |
	a DLEP message, starting from the RFC 5444 Message header, would		| Type value |length (9 + |TLV Type |TLV length |
	appear as follows:		| (value TBD) |optional TLVs) |(TBD) |(8) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Router ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Modem ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Start of optional DLEP |
			| TLVs... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	0 1 2 3		All DLEP messages (signals) begin with this structure. Therefore, in
	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		the following descriptions of specific messages, this header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		structure is assumed, and will not be replicated.
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | |
	| (value TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num | TLV block length (length of |
	| | DLEP order + Sub-TLVs) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Message |TLV Flags=0x10 | Length | Start of DLEP |
	| Block value | | | Sub-TLVs... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	11.1 Message Block TLV Values		10.1 Signal TLV Values
	As mentioned above, all DLEP messages utilize a single RFC 5444		As mentioned above, all DLEP messages begin with the Type value of
	message type, the DLEP_MESSAGE (TBD). DLEP further identifies		the appropriate DLEP signal. Valid DLEP signals are:
	protocol messages by using the 'tlv-type' field in the RFC 5444
	message TLV block. DLEP defines the following Message-Type-
	specific values for the tlv-type field:
	TLV TLV		TLV TLV
	Value Description		Value Description
	=========================================		=========================================
	TBD Attached Peer Discovery		TBD Peer Discovery
	TBD Detached Peer Discovery
	TBD Peer Offer		TBD Peer Offer
			TBD Peer Offer ACK
	TBD Peer Update		TBD Peer Update
	TBD Peer Update ACK		TBD Peer Update ACK
	TBD Peer Termination		TBD Peer Termination
	TBD Peer Termination ACK		TBD Peer Termination ACK
	TBD Neighbor Up		TBD Neighbor Up
	TBD Neighbor Up ACK		TBD Neighbor Up ACK
	TBD Neighbor Down		TBD Neighbor Down
	TBD Neighbor Down ACK		TBD Neighbor Down ACK
	TBD Neighbor Update		TBD Neighbor Update
	TBD Neighbor Address Update
	TBD Neighbor Address Update ACK
	TBD Heartbeat		TBD Heartbeat
	TBD Link Characteristics Request		TBD Link Characteristics Request
	TBD Link Characteristics ACK		TBD Link Characteristics ACK
	In all of the diagrams following, the message layouts begin with the		11. Peer Discovery Message
	RFC 5444 message header.
	12. Peer Discovery Messages
	There are two different types of Peer Discovery Messages, Attached
	and Detached. Attached Peer Discovery Messages are sent by the
	client when it is directly attached to the server (e.g. the client
	exists as a card in the chassis, or it is connected via Ethernet with
	no intervening devices). The Detached Peer Discovery message, on the
	other hand, is sent by a "remote" client -- for example, a client at
	a satellite hub system might use a Detached Discovery Message in
	order to act as a proxy for remote ground terminals. To explain in
	another way, a detached client uses the variable link itself (the
	radio or satellite link) to establish a DLEP session with a remote
	server.
	12.1 Attached Peer Discovery Message
	The Attached Peer Discovery Message is sent by an attached client
	to a server to begin a new DLEP association. The Peer Offer message
	is required to complete the discovery process. The client MAY
	implement its own retry heuristics in the event it (the client)
	determines the Attached Peer Discovery Message has timed out. An
	Attached Peer Discovery Message received from a peer that is already
	in session MUST be processed as if a Peer Termination Message had
	been received. An implementation MAY then process the received
	Attached Peer Discovery Message.
	Note that metric Sub-TLVs MAY be supplied with the Peer Discovery
	order. If metric Sub-TLVs are supplied, they MUST be used as a
	default value for all neighbor sessions established via this peer.
	The Attached Peer Discovery Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Attached |TLV Flags=0x10 | Length =11 + | Sub-TLVs |
	| Peer Discovery| | opt sub-TLVs | as noted below|
	| (Value TDB) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum
	bit is set). No other bits are
	used and MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 22 + size of optional sub-TLVs
	Message Sequence Number - A 16-bit unsigned integer field
	containing a sequence number
	generated by the message
	originator.
	TLV Block - TLVs Length: 14 + size of optional
	sub-TLVs.
	Sub-TLVs:
	Identification (MANDATORY)
	Version (OPTIONAL)
	Peer Type (OPTIONAL)
	Heartbeat Interval (OPTIONAL)
	Heartbeat Threshold (OPTIONAL)
	Link Characteristics ACK Timer
	(OPTIONAL)
	Maximum Data Rate (OPTIONAL)
	Current Data Rate (OPTIONAL)
	Latency (OPTIONAL)
	Expected Forwarding Time (OPTIONAL)
	Resources (OPTIONAL)
	Relative Link Quality (OPTIONAL)
	12.2 Detached Peer Discovery Message
	The Detached Peer Discovery Message is sent by a detached client
	proxy to a server to begin a new DLEP session. The Peer Offer
	message is required to complete the discovery process. The client
	MAY implement its own retry heuristics in the event it (the client)
	determines the Detached Peer Discovery Message has timed out. When
	a DLEP implementation responds to a Detached Discovery Message with
	a Peer Offer, the implementation MUST enter an "in session" state
	with the peer. Any subsequent discovery message received from the
	peer MUST be processed as if a Peer Termination Message had been
	received (e.g. the existing peer session MUST be terminated). An
	implementation MAY then process the received discovery message.
	If metric sub-TLVs (e.g. Maximum Data Rate) are supplied with the
	Detached Peer Discovery message, these metrics MUST be used as the
	initial values for all far-end sessions (neighbors) established via
	the peer.
	The Detached Peer Discovery Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Detached |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as |
	| Peer Discovery| | opt sub-TLVs | noted below |
	| (Value TDB) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (value TBD)
	Message Flags - Set to 0x1 (bit 3,
	mhasseqnum bit is set).
	All other bits are not used
	and MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 22 + size of optional		The Peer Discovery Message is sent to begin a new DLEP association.
	sub-TLVs		The Peer Offer message is required to complete the discovery process.
			Implementations MAY implement their own retry heuristics in cases
			where it is determined the Peer Discovery Message has timed out. A
			Peer Discovery Message received from a participant that is already in
			session MUST be processed as if a Peer Termination Message had been
			received. An implementation MAY then process the received Peer
			Discovery Message.
	Message Sequence Number - A 16-bit unsigned integer		Note that metric data items MAY be supplied with the Peer Discovery,
	field containing a sequence		in order to populate default metric values, or to indicate a static,
	number, generated by the		modem-wide environment. If metrics are supplied with the Peer
	message originator.		Discovery message, these metrics MUST be used as the initial values
			for all neighbors established via the modem.
	TLV Block - TLVs Length: 14 + size of		Given the packet format described in section 11, the initial TLV Type
	optional sub-TLVs.		value is set to DLEP_PEER_DISCOVERY (value TBD). Mandatory TLVs are
			then placed into the packet:
	Sub-TLVs		Mandatory Data Item TLVs:
	Identification (MANDATORY)		- Identification
	Version (OPTIONAL)
	Peer Type (OPTIONAL)
	Heartbeat Interval (OPTIONAL)
	Heartbeat Threshold (OPTIONAL)
	Link Char. ACK Timer (OPTIONAL)
	Maximum Data Rate (OPTIONAL)
	Current Data Rate (OPTIONAL)
	Latency (OPTIONAL)
	Expected Forwarding Time (OPTIONAL)
	Resources (OPTIONAL)
	Relative Link Quality (OPTIONAL)
	As in the Attached Peer Discovery, the client MAY include metric		After the Mandatory data item, implementations MAY place any OPTIONAL
	sub-TLVs. If included, the router SHOULD use these values as defaults		TLVs they support:
	that will apply to all sessions established via this client.
	13. Peer Offer Message		Optional Data Item TLVs:
			- DLEP Version
			- DLEP Peer Type
			- Heartbeat Interval
			- Heartbeat Threshold
			- Link Characteristics ACK Timer
			- Maximum Data Rate
			- Current Data Rate
			- Latency
			- Expected Forwarding Time
			- Resources
			- Relative Link Quality
	The Peer Offer Message is sent by a server to a client in response		12. Peer Offer Message
	to a Peer Discovery Message. The Peer Offer Message is the response		The Peer Offer Message is sent by a DLEP participant in response to a
	to either of the Peer Discovery messages (Attached or Detached),		Peer Discovery Message. Upon receipt, and successful processing, of a
	and completes the DLEP peer session establishment. Upon sending the		Peer Offer message, the recipient MUST respond with a Peer Offer ACK
	Peer Offer Message, the server then enters an "in session" state		message, completing the discovery phase of DLEP. Both DLEP
	with the client. From the client perspective, receipt and successful		participants (router and modem) would then enter an "in session"
	parsing of a Peer Offer order MUST cause the client to enter the "in		state. Any subsequent Discovery messages sent or received on this
	session" state. Any subsequent Discovery messages sent or received		session MUST be considered an error, and the session MUST be
	on this session MUST be considered an error, and the session MUST be
	terminated as if a Peer Termination Message had been received.		terminated as if a Peer Termination Message had been received.
	The Peer Offer Message contains the following fields:		The Peer Offer message MUST be sent to the unicast address of the
			originator of Peer Discovery, regardless of whether the discovery was
			received on the DLEP multicast address (TBD) or on a unicast
			address.
	0 1 2 3		To construct a Peer Offer message, the initial TLV type value is set
	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		to DLEP_PEER_OFFER (value TBD). The Identification data item TLV is
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		placed in the packet next, followed by any OPTIONAL Data Item TLVs
	| Msg Type = |Msg Flg|AddrLen| Message Size |		the implementation supports:
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|DLEP Peer Offer|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as |
	| (Value TBD) | | opt sub-TLVs | indicated |
	| | | | below |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)		Optional Data Item TLVs:
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit		- DLEP Version
	is set). All other bits are unused and		- Peer Type
	MUST be set to '0'.		- IPv4 Address
			- IPv6 Address
			- Status
			- Heartbeat Interval
			- Heartbeat Threshold
			- Link Characteristics ACK Timer
	Message Address Length - 0x0		13. Peer Offer ACK Message
	Message Size - 22 + size of optional sub-TLVs		The Peer Offer ACK message acknowledges receipt of a Peer Offer
			message, and completes the router/modem session establishment for
			DLEP. The Peer Offer ACK message MUST be sent to unicast address of
			the originator of a Peer Offer message. The Peer Offer ACK message
			MAY contain an OPTIONAL Status data item, indicating success or
			failure of the attempt to establish a router/modem session. For
			implementations that do NOT support the Status data item (defined in
			section 10.13 of this document), the Peer Offer ACK message MUST be
			used ONLY to indicate successful session establishment; Peer Offer
			messages that are rejected MUST be silently dropped, allowing the
			Peer Offer to time out.
	Message Sequence Number - A 16-bit unsigned integer field containing		To construct a Peer Offer ACK message, the initial TLV type value is
	a sequence number, generated by the message		set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are
	originator.		placed into the packet next:
	TLV Block - TLV Length: 14 + size of optional sub-TLVs		Mandatory Data Item TLVs:
			- Identification
			- Status
	Sub TLVs		Note that there are NO OPTIONAL data item TLVs specifed for this
	Identification (MANDATORY)		message.
	Version (OPTIONAL)
	Peer Type (OPTIONAL)
	IPv4 Address (OPTIONAL)
	IPv6 Address (OPTIONAL)
	Status (OPTIONAL)
	Heartbeat Interval (OPTIONAL)
	Heartbeat Threshold (OPTIONAL)
	Link Characteristics ACK Timer (OPTIONAL)
	14. Peer Update Message		14. Peer Update Message
	The Peer Update message is sent by a DLEP peer to indicate local		The Peer Update message is an OPTIONAL message, sent by a DLEP peer
	Layer 3 address changes, or for metric changes on a device-wide		to indicate local Layer 3 address changes, or for metric changes on a
	basis. For example, addition of an IPv4 address to the server would		modem-wide basis. For example, addition of an IPv4 address to the
	prompt a Peer Update message to its attached DLEP clients. Also, a		router would prompt a Peer Update message to its attached DLEP
	client that changes its Maximum Data Rate for all destinations MAY		modems. Also, a modem that changes its Maximum Data Rate for all
	reflect that change via a Peer Update Message to its attached server.		destinations MAY reflect that change via a Peer Update Message to its
			attached router(s).
	With Layer 3 address changes, if the client is capable of
	understanding and forwarding this information, the address update
	would prompt any remote DLEP clients (DLEP clients that are on the
	far-end of the variable link) to issue a "Neighbor Update" message to
	their local servers with the new (or deleted) addresses. Clients that
	do not track Layer 3 addresses MUST silently parse and ignore the Peer
	Update Message. Clients that track Layer 3 addresses MUST acknowledge
	the Peer Update with a Peer Update ACK message. Servers receiving a
	Peer Update with metric changes MUST apply the new metric to all
	neighbor sessions established via the client. Peers MAY employ
	heuristics to retransmit Peer Update messages. The sending of Peer
	Update Messages for Layer 3 address changes SHOULD cease when a server
	implementation determines that a client does NOT support Layer 3
	address tracking.
	If metric Sub-TLVs are supplied with the Peer Update message (e.g.
	Maximum Data Rate), these metrics MUST be applied to all neighbor
	sessions accessible via the peer.
	The Peer Update Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as |
	| Update | | opt sub-TLVs | noted below |
	| (Value TDB) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit		Concerning Layer 3 addresses, if the modem is capable of
	is set). All other bits are unused and		understanding and forwarding this information (via proprietary
	MUST be set to '0'.		mechanisms), the address update would prompt any remote DLEP modems
			(DLEP-enabled modems in a remote node) to issue a "Neighbor Update"
			message to their local routers with the new (or deleted) addresses.
			Modems that do not track Layer 3 addresses SHOULD silently parse and
			ignore the Peer Update Message. Modems that track Layer 3 addresses
			MUST acknowledge the Peer Update with a Peer Update ACK message.
			Routers receiving a Peer Update with metric changes MUST apply the
			new metric to all neighbors (remote nodes) accessible via the modem.
			Supporting implementations are free to employ heuristics to
			retransmit Peer Update messages. The sending of Peer Update Messages
			for Layer 3 address changes SHOULD cease when a either participant
			(router or modem) determines that the other implementation does NOT
			support Layer 3 address tracking.
	Message Address Length - 0x0		If metrics are supplied with the Peer Update message (e.g. Maximum
			Data Rate), these metrics are considered to be modem-wide, and
			therefore MUST be applied to all neighbors in the information base
			associated with the router/modem session.
	Message Size - 22 + optional Sub-TLVs		To construct a Peer Update message, the initial TLV type value is set
			to DLEP_PEER_UPDATE (value TBD). The Identification data item TLV is
			placed in the packet next, followed by any OPTIONAL Data Item TLVs.
	Message Sequence Number - A 16-bit unsigned integer containing a		Optional Data Item TLVs:
	sequence number (generated by originator).
	TLV Block - TLV Length: 14 + length of optional		- IPv4 Address
	sub-TLVs.		- IPv6 Address
	Sub TLVs		- Maximum Data Rate
	Identification (MANDATORY)		- Current Data Rate
	IPv4 Address (OPTIONAL)		- Latency
	IPv6 Address (OPTIONAL)		- Expected Forwarding Time
	Maximum Data Rate (OPTIONAL)		- Resources
	Current Data Rate (OPTIONAL)		- Relative Link Quality
	Latency (OPTIONAL)
	Expected Forwarding Time (OPTIONAL)
	Resources (OPTIONAL)
	Relative Link Quality (OPTIONAL)
	15. Peer Update ACK Message		15. Peer Update ACK Message
	A peer sends the Peer Update ACK Message to indicate whether a		The Peer Update ACK message is an OPTIONAL message, and is sent by
	Peer Update Message was successfully processed.		implementations supporting Layer 3 address tracking and/or modem-wide
			metrics to indicate whether a Peer Update Message was successfully
	The Peer Update ACK message contains the following fields:		processed.
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as |
	| Update ACK | | opt sub-TLVs | noted below |
	| (Value TDB) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 22 + size of optional sub-TLVs.
	Message Sequence Number - A 16-bit unsigned integer field containing		To construct a Peer Update ACK message, the initial TLV type value is
	the sequence number from the Neighbor Up		set to DLEP_PEER_UPDATE_ACK (value TBD). The Identification data item
	Message that is being acknowledged.		TLV is placed in the packet next, followed by any OPTIONAL TLVs the
			implementation supports:
	TLV Block - TLV Length: 14 + optional sub-TLVs		Optional Data Item TLVs:
	Sub TLVs		- Status
	Identification (MANDATORY)
	Status (OPTIONAL)
	16. Peer Termination Message		16. Peer Termination Message
	The Peer Termination Message is sent by either the client or the		The Peer Termination Message is sent by a DLEP participant when the
	server when a session needs to be terminated. Transmission of a		router/modem session needs to be terminated. Implementations
	Peer Termination ACK message is required to confirm the		receiving a Peer Termination message MUST send a Peer Termination ACK
	termination process. The sender of the Peer Termination message		message to confirm the termination process. The sender of a Peer
	is free to define its heuristics in event of a timeout. The		Termination message is free to define its heuristics in event of a
	receiver of a Peer Termination Message MUST terminate all		timeout. The receiver of a Peer Termination Message MUST release all
	neighbor sessions and release associated resources. State		resources allocated for the router/modem session, and MUST eliminate
	machines are returned to the "discovery" state. No Neighbor Down		all neighbors in the information base accessible via the router/modem
	messages are sent.		pair represented by the session. Router and modem state machines are
			returned to the "discovery" state. No Neighbor Down messages are
	The Peer Termination Message contains the following fields:		sent.
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as |
	| Termination | | opt sub-TLVs | noted below |
	| (Value TDB) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum
	bit is set). All other bits are
	unused and MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 22 + size of optional sub-TLVs.
	Message Sequence Number - A 16-bit unsigned integer field		To construct a Peer Termination message, the initial TLV type value
	containing a sequence number		is set to DLEP_PEER_TERMINATION (value TBD). The Identification data
	generated by the message originator.		item TLV is placed in the packet next, followed by any OPTIONAL Data
			Item TLVs the implementation supports:
	TLV Block - TLV Length = 14 + optional sub-TLVs		Optional Data Item TLVs:
	Sub TLVs		- Status
	Identification (MANDATORY)
	Status (OPTIONAL)
	17. Peer Termination ACK Message		17. Peer Termination ACK Message
	The Peer Termination Message ACK is sent by a DLEP peer in response		The Peer Termination Message ACK is sent by a DLEP peer in response
	to a received Peer Termination order.		to a received Peer Termination order. Receipt of a Peer Termination
			ACK message completes the teardown of the router/modem session.
	The Peer Termination ACK Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =14 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Peer Term|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as |
	| ACK | | opt sub-TLVs | noted below |
	| (Value TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum
	bit is set). All other bits are
	unused and MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 22 + optional sub-TLVs.
	Message Sequence Number - A 16-bit unsigned integer field		To construct a Peer Termination ACK message, the initial TLV type
	containing the sequence number in		value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The
	the corresponding Peer Termination		Identification data item TLV is placed in the packet next, followed
	Message being acknowledged.		by any OPTIONAL TLVs the implementation supports:
	TLV Block - TLV Length = 14 + optional Sub-TLVs		Optional Data Item TLVs:
	Sub-TLVs		- Status
	Identification (MANDATORY)
	Status (OPTIONAL)
	18. Neighbor Up Message		18. Neighbor Up Message
	A peer sends the Neighbor Up message to report that a new		A DLEP participant sends the Neighbor Up message to report that a new
	potential routing neighbor, or a new destination within the		destination has been detected. A Neighbor Up ACK Message is required
	network, has been detected. A Neighbor Up ACK Message is required		to confirm a received Neighbor Up. A Neighbor Up message can be sent
			either by the modem, to indicate that a new remote node has been
	to confirm a received Neighbor Up. A Neighbor Up message can be		detected, or by the router, to indicate the presence of a new logical
	sent by a client to signal that it (the client) has detected a new		destination (e.g., a Multicast group) exists in the network.
	neighbor, or by the server to indicate that new destinations
	(e.g. Multicast groups) exist within the network.
	The sender of the Neighbor Up Message is free to define its
	retry heuristics in event of a timeout. When a Neighbor Up
	message is received and successfully parsed, the receiver
	should enter an "in session" state with regard to the far-end
	destination, and send an acknowledgement to the originating peer.
	The Neighbor Up Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =23 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Neighbor |TLV Flags=0x10 | Length =20 + | Sub-TLVs as |
	| Up (TBD) | | opt sub-TLVs | noted below |
	| | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 31 + optional Sub-TLVs		The sender of the Neighbor Up Message is free to define its retry
			heuristics in event of a timeout. When a Neighbor Up message is
			received and successfully parsed, the receiver should add knowledge
			of the new destination to its information base, indicating that the
			destination is accessible via the modem/router pair.
	Message Sequence Number - A 16-bit unsigned integer field containing		To construct a Neighbor Up message, the initial TLV type value is set
	a sequence number generated by the message		to DLEP_NEIGHBOR_UP (value TBD). The Identification data item TLV is
	originator.		placed in the packet next, followed by the MAC Address TLV,
			indicating the MAC address of the remote node or Multicast group. The
			implementation would then place any supported OPTIONAL Data Item TLVs
			into the packet:
	TLV Block - TLV Length: 23 + optional Sub-TLVs.		Optional Data Item TLVs:
	Sub-TLVs		- IPv4 Address
	Identification (MANDATORY)		- IPv6 Address
	MAC Address (MANDATORY)		- Maximum Data Rate
	IPv4 Address (OPTIONAL)		- Current Data Rate
	IPv6 Address (OPTIONAL)		- Latency
	Maximum Data Rate (OPTIONAL)		- Expected Forwarding Time
	Current Data Rate (OPTIONAL)		- Resources
	Latency (OPTIONAL)		- Relative Link Factor
	Expected Forwarding Time (OPTIONAL)		- Credit Window Status
	Resources (OPTIONAL)
	Relative Link Factor (OPTIONAL)
	Credit Window Status (OPTIONAL)
	19. Neighbor Up ACK Message		19. Neighbor Up ACK Message
	A peer sends the Neighbor Up ACK Message to indicate whether a		A DLEP participant sends the Neighbor Up ACK Message to indicate
	Neighbor Up Message was successfully processed. When a peer		whether a Neighbor Up Message was successfully processed.
	receives a Neighbor Up ACK message containing a Status Sub-TLV
	with a status code of 0, the receiving peer should enter an "in
	session" state with respect to the far-end destination.
	The Neighbor Up ACK message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 35 |
	| (value TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length = 27 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLVs as |
	| Up ACK (TBD) | | | noted below |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 35
	Message Sequence Number - A 16-bit unsigned integer field containing
	the sequence number from the Neighbor Down
	Message that is being acknowledged.
	TLV Block - TLV Length: 27		To construct a Neighbor Up ACK message, the initial TLV type value is
			set to DLEP_NEIGHBOR_UP_ACK (value TBD). The Identification data item
			TLV is placed in the packet next, followed by the MAC Address TLV,
			containing the MAC address of the DLEP neighbor. The implementation
			would then place any supported OPTIONAL Data Item TLVs into the
			packet:
	Sub-TLVs - Identification (MANDATORY)		Optional Data Item TLVs:
	MAC Address Sub-TLV (MANDATORY)		- Credit Window Status
	Status Sub-TLV (MANDATORY)
	Credit Window Status (OPTIONAL)
	20. Neighbor Down Message		20. Neighbor Down Message
	A DLEP peer sends the Neighbor Down message to report when a		A DLEP peer sends the Neighbor Down message to report when a
	destination (a routing peer or a multicast group) is no longer		destination (a remote node or a multicast group) is no longer
	reachable. The Neighbor Down message MUST contain a MAC Address TLV.		reachable. The Neighbor Down message MUST contain both the
	Any other TLVs present MAY be ignored. A Neighbor Down ACK Message is		Identification data item TLV, and a MAC Address data item TLV. Other
	required to confirm the process. The sender of the Neighbor Down		TLVs as listed are OPTIONAL, and MAY be present if an implementation
	message is free to define its retry heuristics in event of a timeout.		supports them. A Neighbor Down ACK Message MUST be sent by the
	Upon successful receipt and parsing of a Neighbor Down message, the		recipient of a Neighbor Down message to confirm that the relevant
	receiving peer MUST remove all state information for the destination,		data has been removed from the information base. The sender of the
	and send a Neighbor Down ACK message to the originating peer.		Neighbor Down message is free to define its retry heuristics in event
			of a timeout.
	The Neighbor Down Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 31 + optional |
	| (value TBD) | | | sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num | TLVs Length = 23 + optional |
	| | Sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV Type = |TLV Flags=0x10 | Length = 20 + | Sub-TLVs as |
	| DLEP Neighbor | | optional Sub- | noted below |
	| Down (TBD) | | TLV | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 31 + optional TLVs
	Message Sequence Number - A 16-bit unsigned integer field		To construct a Neighbor Down message, the initial TLV type value is
	containing a sequence number generated		set to DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by
	by the message originator.		the mandatory data item TLVs:
	TLV Block - TLV Length: 23 + optional Sub-TLVs		- Identification
			- MAC Address Data item
			- Status data item
	Sub TLVs		Note that there are NO OPTIONAL data item TLVs for this message.
	Identification (MANDATORY)
	MAC Address (MANDATORY)
	Status (OPTIONAL)
	21. Neighbor Down ACK Message		21. Neighbor Down ACK Message
	A peer sends the Neighbor Down ACK Message to indicate whether		A DLEP participant sends the Neighbor Down ACK Message to indicate
	a received Neighbor Down Message was successfully processed. If		whether a received Neighbor Down Message was successfully processed.
	successfully processed, the sending peer MUST remove all state		If successfully processed, the sender of the ACK MUST have removed
	information on the referenced neighbor session.		all entries in the information base that pertain to the referenced
			neighbor. As with the Neighbor Down message, there are NO OPTIONAL
	The Neighbor Down ACK message contains the following fields:		Data Item TLVs defined for the Neighbor Down ACK message.
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 35 |
	| (value TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length = 27 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLVs as |
	| Down ACK (TBD)| | | noted below |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 35
	Message Sequence Number - A 16-bit unsigned integer field containing
	the sequence number from the Neighbor Down
	Message that is being acknowledged.
	TLV Block - TLV Length: 27		To construct a Neighbor Down message, the initial TLV type value is
			set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The Identification data
			item TLV is placed in the packet next, followed by:
	Sub-TLVs - Identification (MANDATORY)		- MAC Address Data item
	MAC Address (MANDATORY)		- Status data item
	Status (MANDATORY)
	22. Neighbor Update Message		22. Neighbor Update Message
	The client sends the Neighbor Update message when a change in link		A DLEP participant sends the Neighbor Update message when it detects
	metric parameters is detected for a destination.		some change in the information base for a given neighbor (remote node
			or multicast group). Some examples of changes that would prompt a
	The Neighbor Update Message contains the following fields:		Neighbor Update message are:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 31 + optional |
	| (value TBD) | | | sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num | TLVs Length = 23 + optional |
	| | Sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|TLV Type = |TLV Flags=0x10 |Length = 20 + |Sub-TLVs as |
	|DLEP Neighbor | |optional Sub- |noted below |
	|Update (TBD) | |TLVs | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum
	bit is set). All other bits are
	unused and MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 31 + optional TLVs
	Message Sequence Number - A 16-bit unsigned integer field
	containing a sequence number,
	generated by the message originator.
	TLV Block - TLVs Length - 23 + optional Sub-TLVs.
	Sub TLVs
	Identification (MANDATORY)
	MAC Address (MANDATORY)
	Maximum Data Rate (OPTIONAL)
	Current Data Rate (OPTIONAL)
	Latency (OPTIONAL)
	Resources (OPTIONAL)
	Relative Link Quality (OPTIONAL)
	Credit Window Status (OPTIONAL)
	Credit Grant (OPTIONAL)
	Credit Request (OPTIONAL)
	23. Neighbor Address Update Message
	The client sends the Neighbor Address Update message when a change
	in Layer 3 addressing is detected for a neighbor session.
	The Neighbor Address Update Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =23 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Neighbor |TLV Flags=0x10 | Length =20 + | Sub-TLVs as |
	| Address Update| | opt sub-TLVs | noted below |
	|(TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is
	set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 31 + optional TLVs
	Message Sequence Number - A 16-bit unsigned integer field
	containing a sequence number,
	generated by the message originator.
	TLV Block - TLVs Length - 23 + optional Sub-TLVs.
	Sub TLVs
	Identification Sub-TLV (MANDATORY)
	MAC Address Sub-TLV (MANDATORY)
	IPv4 Address Sub-TLV (OPTIONAL)
	IPv6 Address Sub-TLV (OPTIONAL)
	24. Neighbor Address Update ACK Message
	The server sends the Neighbor Address Update ACK Message to
	indicate whether a Neighbor Address Update Message was
	successfully processed.
	The Neighbor Address Update ACK message contains the following
	fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 35 |
	| (value TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length = 27 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLVs as |
	| Address Update| | | noted below |
	| ACK (TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0
	Message Size - 35
	Message Sequence Number - A 16-bit unsigned integer field containing
	the sequence number from the Neighbor Down
	Message that is being acknowledged.
	TLV Block - TLV Length: 27
	Sub TLVs
	Identification Sub-TLV (MANDATORY)
	MAC Address Sub-TLV (MANDATORY)
	Status Sub-TLV (MANDATORY)
	25. Heartbeat Message
	A Heartbeat Message is sent by a peer every N seconds, where N is
	defined in the "Heartbeat Interval" field of the discovery message.
	The message is used by peers to detect when a DLEP session partner
	is no longer communicating. Peers SHOULD allow some integral number
	of heartbeat intervals (default 4) to expire with no traffic on the
	session before initiating DLEP session termination procedures.
	The Heartbeat Message contains the following fields:
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 22 |
	| (value TBD) | | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length = 14 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Heartbeat|TLV Flags=0x10 | Length = 11 | Sub-TLVs as |
	| (TBD) | | | noted below |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is
	set). All other bits are unused and SHOULD
	be set to '0'.
	Message Address Length - 0x0		- Change in link metrics (e.g., Data Rates)
			- Layer 3 addressing change (for implementations that support it)
	Message Size - 22		To construct a Neighbor Update message, the initial TLV type value is
			set to DLEP_NEIGHBOR_UPDATE (value TBD). Following the signal TLV are
			the mandatory Data Item TLVs:
	Message Sequence Number - A 16-bit unsigned integer field containing		Identification Data Item TLV
	a sequence number generated by the message		MAC Address data item TLV
	originator.
	TLV Block - TLV Length = 14		After placing the mandatory data item TLVs into the packet, the
			implementation would place any supported OPTIONAL data item TLVs.
			Possible OPTIONAL data item TLVs are:
	Sub TLVs -		- IPv4 Address
	Identification Sub-TLV (MANDATORY)		- IPv6 Address
			- Maximum Data Rate
			- Current Data Rate
			- Latency
			- Resources
			- Relative Link Quality
			- Credit Window Status
			- Credit Grant
			- Credit Request
	26. Link Characteristics Request Message		23. Heartbeat Message
	The Link Characteristics Request Message is sent by the server to		A Heartbeat Message is sent by a DLEP participant every N seconds,
	the client when the server detects that a different set of		where N is defined in the "Heartbeat Interval" field of the discovery
	transmission characteristics is necessary (or desired) for the		message. Note that implementations omitting the Heartbeat Interval
	type of traffic that is flowing on the link. It is important to		effectively set the interval to an infinite value, therefore, in
	note that the link can be a logical link for a multicast session		those cases, this message would NOT be sent.
	where more than one remote neighbor participates. The request
	contains either a Current Data Rate (CDR) TLV to request a different
	amount of bandwidth than what is currently allocated, a Latency
	TLV to request that traffic delay on the link not exceed the
	specified value, or both. A Link Characteristics ACK Message is
	required to complete the request. Implementations are free to
	define their retry heuristics in event of a timeout. Issuing a
	Link Characteristics Request with ONLY the MAC Address TLV is a
	mechanism a peer MAY use to request metrics (via the Link
	Characteristics ACK) from its partner.
	The Link Characteristics Request Message contains the following		The message is used by participants to detect when a DLEP session
	fields:		partner (either the modem or the router) is no longer communicating.
			Participants SHOULD allow some integral number of heartbeat intervals
			(default 4) to expire with no traffic on the router/modem session
			before initiating DLEP session termination procedures.
	0 1 2 3		To construct a Heartbeat message, the initial TLV type value is set
	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		to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		mandatory data item TLVs:
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =23 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Link Char|TLV Flags=0x10 | Length =20 + | Sub-TLVs as |
	| Request (TBD) | | opt sub-TLVs | noted below |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)		- Identification
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit		Note that there are NO OPTIONAL data item TLVs for this message.
	is set). All other bits are unused and
	MUST be set to '0'.
	Message Address Length - 0x0		24. Link Characteristics Request Message
	Message Size - 31 + length of optional (Current Data		The Link Characteristics Request Message is an OPTIONAL message, and
	Rate and/or Latency) Sub-TLVs		is sent by the router to request that the modem initiate changes for
			specific characteristics of the link. Since the request specifies a
			neighbor, it can reference either a real destination (e.g., a remote
			node), or a logical destination (e.g., a multicast destination)
			within the network.
	Message Sequence Number - A 16-bit unsigned integer field containing		The Link Characteristics Request message contains either a Current
	a sequence number generated by the message		Data Rate (CDR) TLV to request a different amount of bandwidth than
	originator.		what is currently allocated, a Latency TLV to request that traffic
			delay on the link not exceed the specified value, or both. A Link
			Characteristics ACK Message is required to complete the request.
			Implementations are free to define their retry heuristics in event of
			a timeout. Issuing a Link Characteristics Request with ONLY the MAC
			Address TLV is a mechanism a peer MAY use to request metrics (via the
			Link Characteristics ACK) from its partner.
	TLV Block - Length: 23 + optional Sub-TLVs		To construct a Link Characteristics Request message, the initial TLV
			type value is set to DLEP_NEIGHBOR_LINK_CHAR_REQ (value TBD).
			Following the signal TLV are the mandatory Data Item TLVs:
	Sub TLVs		Identification Data Item TLV
	Identification Sub-TLV (MANDATORY)		MAC Address data item TLV
	MAC Address Sub-TLV (MANDATORY)
	Current Data Rate Sub-TLV - if present,
	this value represents the requested data
	rate in bits per second (bps). (OPTIONAL)
	Latency TLV - if present, this value
	represents the maximum latency, in
	milliseconds, desired on the link.
	(OPTIONAL)
	27. Link Characteristics ACK Message		After placing the mandatory data item TLVs into the packet, the
			implementation would place any supported OPTIONAL data item TLVs.
			Possible OPTIONAL data item TLVs are:
	The Link Characteristics ACK Message is sent by the client to the		Current Data Rate - If present, this value represents the NEW (or
	server letting the server know the success (or failure) of the		unchanged, if the request is denied) Current
	requested change in link characteristics. The Link Characteristics		Data Rate in bits per second (bps).
	ACK message SHOULD contain a complete set of metric TLVs. It MUST
	contain the same TLV types as the request. The values in the
	metric TLVs in the Link Characteristics ACK message MUST reflect
	the link characteristics after the request has been processed.
	The Link Characteristics ACK Message contains the following fields:		Latency - If present, this value represents the maximum
			desired latency (e.g., it is a not-to-exceed
			value) in milliseconds on the link.
	0 1 2 3		25. Link Characteristics ACK Message
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Msg Type = |Msg Flg|AddrLen| Message Size |
	| DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt |
	| (value TBD) | | | sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Seq Num |TLVs Length =23 + opt sub-TLVs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DLEP Link Char|TLV Flags=0x10 | Length =20 + | Sub-TLVs as |
	| ACK (TBD) | | opt sub-TLVs | noted below |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type - DLEP_MESSAGE (Value TBD)		The LInk Characteristics ACK message is an OPTIONAL message, and is
			sent by modems supporting it to the router letting the router know
			the success or failure of a requested change in link characteristics.
			The Link Characteristics ACK message SHOULD contain a complete set
			of metric data item TLVs. It MUST contain the same TLV types as the
			request. The values in the metric data item TLVs in the Link
			Characteristics ACK message MUST reflect the link characteristics
			after the request has been processed.
	Message Flags - Set to 0x1 (bit 3, mhasseqnum bit		To construct a Link Characteristics Request ACK message, the initial
	is set). All other bits are unused and		TLV type value is set to DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD).
	MUST be set to '0'.		Following the signal TLV are the mandatory Data Item TLVs:
	Message Address Length - 0x0		Identification Data Item TLV
			MAC Address data item TLV
	Message Size - 31 + length of optional (Current Data		After placing the mandatory data item TLVs into the packet, the
	Rate and/or Latency) TLVs		implementation would place any supported OPTIONAL data item TLVs.
			Possible OPTIONAL data item TLVs are:
	Message Sequence Number - A 16-bit unsigned integer field containing		Current Data Rate - If present, this value represents the requested
	the sequence number that appeared on the		data rate in bits per second (bps).
	corresponding Link Characteristics Request
	message.
	TLV Block - TLVs Length = 23 + Optional TLVs		Latency - If present, this value represents the NEW
			maximum latency (or unchanged, if the request
			is denied), expressed in milliseconds, on the
			link.
	Sub TLVs		26. Security Considerations
	Identification Sub-TLV (MANDATORY)
	MAC Address Sub-TLV (MANDATORY)
	Maximum Data Rate Sub-TLV (OPTIONAL)
	Current Data Rate Sub-TLV - if present,		The protocol does not contain any mechanisms for security (e.g.
	this value represents the NEW (or		authentication or encryption). The protocol assumes that any security
	unchanged, if the request is denied)		would be implemented in the underlying transport (for example, by use
	Current Data Rate in bits per second (bps).		of DTLS or some other mechanism), and is therefore outside the scope
	(OPTIONAL)		of this document.
	Latency Sub-TLV - if present, this value
	represents the NEW maximum latency (or
	unchanged, if the request is denied),
	expressed in milliseconds, on the link.
	(OPTIONAL)
	Resources Sub-TLV (OPTIONAL)		27. IANA Considerations
	Relative Link Quality Sub-TLV (OPTIONAL)		This section specifies requests to IANA.
	28. Security Considerations		27.1 Registrations
	The protocol does not contain any mechanisms for security (e.g.		This specification defines:
	authentication or encryption). The protocol assumes that any
	security would be implemented in the underlying transport (for
	example, by use of DTLS or some other mechanism), and is
	therefore outside the scope of this document.
	29. IANA Considerations		o A new repository for DLEP signals, with fifteen values currently
			assigned.
	This section specifies requests to IANA.		o Reservation of numbering space for Experimental DLEP signals.
	29.1 TLV Registrations		o A new repository for DLEP Data Items, with eighteen values
			currently assigned.
	This specification defines:		o Reservation of numbering space in the Data Items repository for
			experimental data items.
	o One TLV types which must be allocated from the 0-223 range		o A request for allocation of a well-known port for DLEP
	of the "Assigned Message TLV Types" repository of [RFC5444].		communication.
	o A new repository for DLEP orders, with seventeen values currently		o A request for allocation of a multicast address for DLEP
	assigned.		discovery.
	o A new repository for DLEP Sub-TLV assignments with nineteen values		27.2 Expert Review: Evaluation Guidelines
	currently assigned.
	29.2 Expert Review: Evaluation Guidelines		No additional guidelines for expert review are anticipated.
	For the registries for TLV type extensions where an Expert Review is		27.3 Signal (Message) TLV Type Registration
	required, the designated expert SHOULD take the same general
	recommendations into consideration as are specified by [RFC5444].
	29.3 Message TLV Type Registration		A new repository must be created with the values of the DLEP signals.
			Valid signals are:
	The Message TLV specified below must be allocated from the "Message		o Peer Discovery
	TLV Types" namespace of [RFC5444].		o Peer Offer
			o Peer Offer ACK
			o Peer Update
			o Peer Update ACK
			o Peer Termination
			o Peer Termination ACK
			o Neighbor Up
			o Neighbor Up ACK
			o Neighbor Down
			o Neighbor Down ACK
			o Neighbor Update
			o Heartbeat
			o Link Characteristics Request
			o Link Characteristics ACK
	o DLEP_MESSAGE		It is also requested that the repository contain space for
			experimental signal types.
	29.4 DLEP Order Registration		27.4 DLEP Data Item Registrations
	A new repository must be created with the values of the DLEP orders.		A new repository for DLEP Data Items must be created. Valid Data
	Valid orders are:		Items are:
	o Attached Peer Discovery Message		o Identification
	o Detached Peer Discovery Message		o DLEP Version
	o Peer Offer Message		o Peer Type
	o Peer Update Message		o MAC Address
	o Peer Update ACK Message		o IPv4 Address
	o Peer Termination Message		o IPv6 Address
	o Peer Termination ACK Message		o Maximum Data Rate
	o Neighbor Up Message		o Current Data Rate
	o Neighbor Up ACK Message		o Latency
	o Neighbor Down Message		o Expected Forwarding Time
	o Neighbor Down ACK Message		o Resources
	o Neighbor Update Message		o Relative Link Quality
	o Neighbor Address Update Message		o Status
	o Neighbor Address Update ACK Message		o Heartbeat Interval/Threshold
	o Heartbeat Message		o Link Characteristics ACK Timer
	o Link Characteristics Request Message		o Credit Window Status
	o Link Characteristics ACK Message		o Credit Grant
			o Credit Request
	This registry should be created according to the guidelines for		It is also requested that the registry allocation contain space for
	'Message-Type-Specific TLV' registration as specified in section		experimental data items.
	6.2.1 of [RFC5444].
	29.5 DLEP Sub-TLV Type Registrations		27.5 DLEP Well-known Port
	A new repository for DLEP Sub-TLVs must be created. Valid Sub-TLVs are:		It is requested that IANA allocate a well-known port number for DLEP
			communication.
	o Identification Sub-TLV		27.6 DLEP Multicast Address
	o DLEP Version Sub-TLV
	o Peer Type Sub-TLV
	o MAC Address Sub-TLV
	o IPv4 Address Sub-TLV
	o IPv6 Address Sub-TLV
	o Maximum Data Rate Sub-TLV
	o Current Data Rate Sub-TLV
	o Latency Sub-TLV
	o Expected Forwarding Time Sub-TLV
	o Resources Sub-TLV
	o Relative Link Quality Sub-TLV
	o Status Sub-TLV
	o Heartbeat Interval Sub-TLV
	o Heartbeat Threshold Sub-TLV
	o Link Characteristics ACK Timer Sub-TLV
	o Credit Window Status Sub-TLV
	o Credit Grant Sub-TLV
	o Credit Request Sub-TLV
	It is also requested that the registry allocation contain space		It is requested that IANA allocate a multicast address for DLEP
	reserved for experimental sub-TLVs.		discovery messages.
	30. Appendix A.		30. Appendix A.
	Peer Level Message Flows		30.1 Peer Level Message Flows
	*Modem Device (Client) Restarts Discovery		30.1.1 Modem Device Restarts Discovery
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
			<-------Peer Discovery--------- Modem initiates discovery
	<-------Peer Discovery--------- Client initiates discovery		---------Peer Offer-----------> Router detects a problem, sends
			w/ Non-zero Status TLV Peer Offer w/Status TLV indicating
	---------Peer Offer-----------> Server detects a problem, sends
	w/ Non-zero Status TLV Peer Offer w/ Status TLV indicating
	the error.		the error.
	Client accepts failure, restarts		Modem accepts failure, restarts
	discovery process.		discovery process.
	<-------Peer Discovery--------- Client initiates discovery		<-------Peer Discovery--------- Modem initiates discovery
	---------Peer Offer-----------> Server accepts, sends Peer Offer		---------Peer Offer-----------> Router accepts, sends Peer Offer
	w/ Zero Status TLV w/ Status TLV indicating success.		w/ Zero Status TLV w/ Status TLV indicating success.
	Discovery completed.		Discovery completed.
	*Modem Device Detects Peer Offer Timeout		30.1.2 Modem Device Detects Peer Offer Timeout
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<-------Peer Discovery--------- Client initiates discovery,		<-------Peer Discovery--------- Modem initiates discovery, starts
	starts a guard timer.		a guard timer.
	Client guard timer expires.		Modem guard timer expires. Modem
	Client restarts discovery process.		restarts discovery process.
	<-------Peer Discovery--------- Client initiates discovery,		<-------Peer Discovery--------- Modem initiates discovery, starts
	starts a guard timer.		a guard timer.
	---------Peer Offer-----------> Server accepts, sends Peer Offer		---------Peer Offer-----------> Router accepts, sends Peer Offer
	w/ Zero Status TLV w/ Status TLV indicating success.		w/ Zero Status TLV w/ Status TLV indicating success.
	Discovery completed.		Discovery completed.
	*Server Peer Offer Lost		30.1.3 Router Peer Offer Lost
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<-------Peer Discovery--------- Client initiates discovery,		<-------Peer Discovery--------- Modem initiates discovery, starts
	starts a guard timer.		a guard timer.
	---------Peer Offer-------|| Server offers availability		---------Peer Offer-------|| Router offers availability
	Client times out on Peer Offer,		Modem times out on Peer Offer,
	restarts discovery process.		restarts discovery process.
	<-------Peer Discovery--------- Client initiates discovery		<-------Peer Discovery--------- Modem initiates discovery
	---------Peer Offer-----------> Server detects subsequent discovery,		---------Peer Offer-----------> Router detects subsequent
	internally terminates the previous,		discovery, internally terminates
	accepts the new association, sends		the previous, accepts the new
	Peer Offer w/ Status TLV indicating		association, sends Peer Offer
	success.		w/Status TLV indicating success.
	Discovery completed.		Discovery completed.
	*Discovery Success		30.1.4 Discovery Success
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<-------Peer Discovery--------- Client initiates discovery		<-------Peer Discovery--------- Modem initiates discovery
	---------Peer Offer-----------> Server offers availability		---------Peer Offer-----------> Router offers availability
	-------Peer Heartbeat--------->		-------Peer Heartbeat--------->
	<-------Peer Heartbeat---------		<-------Peer Heartbeat---------
	-------Peer Heartbeat--------->		-------Peer Heartbeat--------->
	<==============================> Neighbor Sessions		<==============================> Neighbor Sessions
	<-------Peer Heartbeat---------		<-------Peer Heartbeat---------
	-------Peer Heartbeat--------->		-------Peer Heartbeat--------->
	--------Peer Term Req---------> Terminate Request		--------Peer Term Req---------> Terminate Request
	<--------Peer Term Res--------- Terminate Response		<--------Peer Term Res--------- Terminate Response
	*Server Detects a Heartbeat timeout		30.1.5 Router Detects a Heartbeat timeout
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<-------Peer Heartbeat---------		<-------Peer Heartbeat---------
	-------Peer Heartbeat--------->		-------Peer Heartbeat--------->
	||---Peer Heartbeat---------		||---Peer Heartbeat---------
	~ ~ ~ ~ ~ ~ ~		~ ~ ~ ~ ~ ~ ~
	-------Peer Heartbeat--------->		-------Peer Heartbeat--------->
	||---Peer Heartbeat---------		||---Peer Heartbeat---------
	Server Heartbeat Timer expires,		Router Heartbeat Timer expires,
	detects missing heartbeats. Server		detects missing heartbeats. Router
	takes down all neighbor sessions		takes down all neighbor sessions
	and terminates the Peer association.		and terminates the Peer
			association.
	------Peer Terminate ---------> Peer Terminate Request		------Peer Terminate ---------> Peer Terminate Request
	Client takes down all neighbor		Modem takes down all neighbor
	sessions, then acknowledges the		sessions, then acknowledges the
	Peer Terminate		Peer Terminate
	<----Peer Terminate ACK--------- Peer Terminate ACK		<----Peer Terminate ACK--------- Peer Terminate ACK
	*Client Detects a Heartbeat timeout		30.1.6 Modem Detects a Heartbeat timeout
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<-------Peer Heartbeat---------		<-------Peer Heartbeat---------
	-------Peer Heartbeat------||		-------Peer Heartbeat------||
	<-------Peer Heartbeat---------		<-------Peer Heartbeat---------
	~ ~ ~ ~ ~ ~ ~		~ ~ ~ ~ ~ ~ ~
	-------Peer Heartbeat------||		-------Peer Heartbeat------||
	<-------Peer Heartbeat---------		<-------Peer Heartbeat---------
	Client Heartbeat Timer expires,		Modem Heartbeat Timer expires,
	detects missing heartbeats. Modem		detects missing heartbeats. Modem
	takes down all neighbor sessions		takes down all neighbor sessions
	and terminates the Peer association.
	<-------Peer Terminate-------- Peer Terminate Request		<-------Peer Terminate-------- Peer Terminate Request
	Server takes down all neighbor		Router takes down all neighbor
	sessions, then acknowledges the		sessions, then acknowledges the
	Peer Terminate		Peer Terminate
	------Peer Terminate ACK-----> Peer Terminate ACK		------Peer Terminate ACK-----> Peer Terminate ACK
	*Peer Terminate (from Client) Lost		30.1.7 Peer Terminate (from Modem) Lost
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	||------Peer Terminate-------- Client Peer Terminate Request		||------Peer Terminate-------- Modem Peer Terminate Request
	Server Heartbeat times out,		Router Heartbeat times out,
	terminates association.		terminates association.
	--------Peer Terminate-------> Server Peer Terminate		--------Peer Terminate-------> Router Peer Terminate
	<-----Peer Terminate ACK------ Client sends Peer Terminate ACK		<-----Peer Terminate ACK------ Modem sends Peer Terminate ACK
	*Peer Terminate (from server) Lost		30.1.8 Peer Terminate (from Router) Lost
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	-------Peer Terminate--------> Server Peer Terminate Request		-------Peer Terminate--------> Router Peer Terminate Request
	Client HB times out,		Modem HB times out,
	terminates association.		terminates association.
	<------Peer Terminate-------- Client Peer Terminate		<------Peer Terminate-------- Modem Peer Terminate
	------Peer Terminate ACK-----> Peer Terminate ACK		------Peer Terminate ACK-----> Peer Terminate ACK
	Neighbor Level Message Flows		30.2 Neighbor Specific Message Flows
			30.2.1 Modem Neighbor Up Lost
	*Client Neighbor Up Lost
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	||-----Neighbor Up ------------ Client sends Neighbor Up		||-----Neighbor Up ------------ Modem sends Neighbor Up
	Client timesout on ACK		Modem timesout on ACK
	<------Neighbor Up ------------ Client sends Neighbor Up		<------Neighbor Up ------------ Modem sends Neighbor Up
	------Neighbor Up ACK---------> Server accepts the neighbor		------Neighbor Up ACK---------> Router accepts the neighbor
	session		session
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	. . . . . . . .		. . . . . . . .
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	*Server Detects Duplicate Neighbor Ups		30.2.2 Router Detects Duplicate Neighbor Ups
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<------Neighbor Up ------------ Client sends Neighbor Up		<------Neighbor Up ------------ Modem sends Neighbor Up
	------Neighbor Up ACK-------|| Server accepts the neighbor		------Neighbor Up ACK-------|| Router accepts the neighbor
	session		session
	Client timesout on ACK		Modem timesout on ACK
	<------Neighbor Up ------------ Client resends Neighbor Up		<------Neighbor Up ------------ Modem resends Neighbor Up
	Server detects duplicate		Router detects duplicate Neighbor,
	Neighbor, takes down the		takes down the previous, accepts
	previous, accepts the new		the new Neighbor.
	Neighbor.
	------Neighbor Up ACK---------> Server accepts the neighbor		------Neighbor Up ACK---------> Router accepts the neighbor
	session		session
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	. . . . . . . .		. . . . . . . .
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	*Neighbor Up, No Layer 3 Addresses		30.2.3 Neighbor Up, No Layer 3 Addresses
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<------Neighbor Up ------------ Client sends Neighbor Up		<------Neighbor Up ------------ Modem sends Neighbor Up
	------Neighbor Up ACK---------> Server accepts the neighbor		------Neighbor Up ACK---------> Router accepts the neighbor
	session		session
	Server ARPs for IPv4 if defined.		Router ARPs for IPv4 if defined.
	Server drives ND for IPv6 if		Router drives ND for IPv6 if
	defined.		defined.
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	. . . . . . . .		. . . . . . . .
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	*Neighbor Up with IPv4, No IPv6		30.2.4 Neighbor Up with IPv4, No IPv6
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<------Neighbor Up ------------ Client sends Neighbor Up with		<------Neighbor Up ------------ Modem sends Neighbor Up with
	the IPv4 TLV		the IPv4 TLV
	------Neighbor Up ACK---------> Server accepts the neighbor		------Neighbor Up ACK---------> Router accepts the neighbor
	session		session
	Server drives ND for IPv6 if		Router drives ND for IPv6 if
	defined.		defined.
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	. . . . . . . .		. . . . . . . .
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	*Neighbor Up with IPv4 and IPv6		30.2.5 Neighbor Up with IPv4 and IPv6
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	<------Neighbor Up ------------ Client sends Neighbor Up with		<------Neighbor Up ------------ Modem sends Neighbor Up with
	the IPv4 and IPv6 TLVs		the IPv4 and IPv6 TLVs
	------Neighbor Up ACK---------> Server accepts the neighbor		------Neighbor Up ACK---------> Router accepts the neighbor
	session		session
	<------Neighbor Update--------- Client Neighbor Metrics		<------Neighbor Update--------- Modem Neighbor Metrics
	. . . . . . . .		. . . . . . . .
	<------Neighbor Update--------- Client Neighbor Metrics
	*Neighbor Session Success		30.2.6 Neighbor Session Success
	Server Client Message Description		Router Modem Message Description
	====================================================================		====================================================================
	---------Peer Offer-----------> Server offers availability		---------Peer Offer-----------> Router offers availability
	-------Peer Heartbeat--------->		-------Peer Heartbeat--------->
	<------Neighbor Up ----------- Client		<------Neighbor Up ----------- Modem
	------Neighbor Up ACK--------> Server		------Neighbor Up ACK--------> Router
	<------Neighbor Update--------- Client		<------Neighbor Update--------- Modem
	. . . . . . . .		. . . . . . . .
	<------Neighbor Update--------- Client		<------Neighbor Update--------- Modem
	Client initiates the terminate		Modem initiates the terminate
	<------Neighbor Down ---------- Client		<------Neighbor Down ---------- Modem
	------Neighbor Down ACK-------> Server		------Neighbor Down ACK-------> Router
	or		or
	Server initiates the terminate		Router initiates the terminate
	------Neighbor Down ----------> Server		------Neighbor Down ----------> Router
	<------Neighbor Down ACK------- Client		<------Neighbor Down ACK------- Modem
	Acknowledgements		Acknowledgements
	The authors would like to acknowledge the influence and contributions		The authors would like to acknowledge the influence and contributions
	of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick		of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick
	Taylor, and John Dowdell.		Taylor, John Dowdell, Nelson Powell, Bow-Nan Cheng, and Henning
			Rogge.
	Normative References		Normative References
	[RFC5444] Clausen, T., Ed,. "Generalized Mobile Ad Hoc Network (MANET)
	Packet/Message Format", RFC 5444, Februar, 2009.
	[RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics",		[RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics",
	RFC 5578, February 2010.		RFC 5578, February 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.
	Informative References		Informative References
	[DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security",		[DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security",
	RFC 4347, April 2006.		RFC 4347, April 2006.
	Author's Addresses		Author's Addresses
	Stan Ratliff		Stan Ratliff
	Cisco		Cisco
End of changes. 416 change blocks.
	1926 lines changed or deleted		1384 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/