DLEP and RFC 5444

On Thu, Mar 15, 2012 at 11:33 AM, S= tan Ratliff <sra= tliff@cisco.com> wrote:

Ulrich,

On Mar 15, 2012, at 2:23 PM, Ulrich Herberg wrote:

Hi,

I have started reviewing the -02 DLEP revision. I have not yet
reviewed details of all the different message types, because I first
have some more general comments.

Overall comments:
- I am not a fan of the sub-TLVs and orders. There are
message-specific TLV types. Using sub-TLVs defeats the purpose of
RFC5444 and requires an additional parser.

I'm still not getting the message-specific TLV types, but perhaps I'= ;m being dense. I'll go back and look at RFC 5444. Again, the whole con= cept was done to minimize the impact of DLEP on the RFC 5444 TLV space.

Refer to Section 6.2 of RFC= 5444:

o  TLV Type values 128-223 are Message-Type-specific TLV Type values,
      relevant only in the context of the containing Message Type.
      Registration of TLV Type values within the 128-223 interval
      requires that a registry in the 128-223 interval exists for a
      specific Message Type value (see Section 6.2.1), and registrations
      are made in accordance with the allocation policies specified for
      these Message-Type-specific registries.

<= /div>

=C2=A0

- I wonder if it is not possible to use the Address Blocks of RFC5444
messages, e.g. for Neighbor Up / Down.

This has been discussed on *several* occasions. At least in the environment= s where I deploy product, my users want to deploy *both* IPv4 and IPv6 simu= ltaneously. We can't transport both address types in the same message u= sing address blocks.

I admit that because of my = personal interests, I have not followed the DLEP discussion as closely as f= or the other MANET document, so I apologize if that has already been discus= sed and agreed on by the WG. That may have been something which could have = been considered for RFC5444, to allow for defining a different address leng= th for each address block. But well, not worth discussing it; too late ;-)= =C2=A0

=C2=A0

- There are many message types. It would be nice to reduce the number.
For example, in NHDP, neighbors can also be marked as Up/Down (well,
as HEARD/SYM/LOST) without extra message types and using the address
compression of the Address Blocks.
- Sections describing the order / sub-TLV format also contain their
processing and generation instructions. I very much like the way it is
done in NDHP with separate sections, and detailed instructions for the
implementer how to parse / generate messages and TLVs.

I thought we had pretty much done that with this draft. Can you give me an = example of where you see the text as deficient?

The message flow is depicted in Appendix A. Compare= d to other MANET drafts and RFCs (like RFC6130), there is no normative desc= ription how this message flow is handled exactly. For example, how to handl= e messages by external extensions (security extensions) before and after ge= nerating/parsing, which timers to use to wait before a message is considere= d lost, what happens if messages are out of order or have invalid informati= on. In the appendix, some of the timers and session establishment are menti= oned, but they are not specified in the main document, other than in a brie= f overview in section 6. Maybe that does not have any influence on interope= rability, but since there are a lot of request-reply type messages, I doubt= that.

=C2=A0

- It would be easier to read if xml2rfc was used to generate the
document. The pages don't allign and the table of contents is missing several sections.

Hmmm... sounds like I need an xml2rfc primer... ;-) =C2=A0Are you volunteer= ing to give me a lesson in Paris?

Sure!= If you invite me for a beer ;-)

Regards

Ulrich

=C2=A0

Regards,
Stan

More comments follow below: (marked with UH> )

Best
Ulrich

Mobile Ad hoc Networks Working =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0S. Rat= liff
Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B. Berry
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 G. Harrison
Intended status: Standards Track =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D. Satterwhite
Expires: August 10, 2012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cisco= Systems
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 S. Jury
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0NetApp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 6, 2012

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dynamic Lin= k Exchange Protocol (DLEP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 draft-ietf-manet-dlep-02

Abstract

=C2=A0 When routing devices rely on modems to effect communications over =C2=A0 wireless links, they need timely and accurate knowledge of the
=C2=A0 characteristics of the link (speed, state, etc.) in order to make =C2=A0 forwarding decisions. In mobile or other environments where these =C2=A0 characteristics change frequently, manual configurations or the
=C2=A0 inference of state through routing or transport protocols does not<= br> =C2=A0 allow the router to make the best decisions. A bidirectional, event= -
=C2=A0 driven communication channel between the router and the modem is =C2=A0 necessary.

=C2=A0 UH> s/is necessary/is specified in this document/

Status of this Memo

=C2=A0 This Internet-Draft is submitted to IETF in full conformance with t= he
=C2=A0 provisions of BCP 78 and BCP 79.

=C2=A0 Internet-Drafts are working documents of the Internet Engineering =C2=A0 Task Force (IETF), its areas, and its working groups. =C2=A0Note th= at
=C2=A0 other groups may also distribute working documents as Internet-
=C2=A0 Drafts.

=C2=A0 Internet-Drafts are draft documents valid for a maximum of six mont= hs
=C2=A0 and may be updated, replaced, or obsoleted by other documents at an= y
=C2=A0 time. =C2=A0It is inappropriate to use Internet-Drafts as reference=
=C2=A0 material or to cite them other than as "work in progress."= ;

=C2=A0 The list of current Internet-Drafts can be accessed at
=C2=A0 http://www.ietf.org/ietf/1id-abstracts.txt.

=C2=A0 The list of Internet-Draft Shadow Directories can be accessed at =C2=A0 http:= //www.ietf.org/shadow.html.

=C2=A0 This Internet-Draft will expire on August 10, 2012 =C2=A0 =C2=A0.
Copyright Notice

=C2=A0 Copyright (c) 2012 IETF Trust and the persons identified as the
=C2=A0 document authors. =C2=A0All rights reserved.

=C2=A0 This document is subject to BCP 78 and the IETF Trust's Legal =C2=A0 Provisions Relating to IETF Documents

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 1]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 February 2012

=C2=A0 (http://trustee.ietf.org/license-info) in effect on the date of<= br> =C2=A0 publication of this document. =C2=A0Please review these documents =C2=A0 carefully, as they describe your rights and restrictions with respe= ct
=C2=A0 to this document. =C2=A0Code Components extracted from this documen= t must
=C2=A0 include Simplified BSD License text as described in Section 4.e of<= br> =C2=A0 the Trust Legal Provisions and are provided without warranty as
=C2=A0 described in the Simplified BSD License.

Table of Contents

=C2=A0 1. =C2=A0Introduction . . . . . . . . . . . . . . . . . . . . . . .= . . =C2=A03
=C2=A0 =C2=A0 1.1 =C2=A0 Requirements . . . . . . . . . . . . . . . . . . = . . . . . =C2=A06
=C2=A0 2. =C2=A0Assumptions =C2=A0. . . . . . . . . . . . . . . . . . . . = . . . . . =C2=A06
=C2=A0 3. =C2=A0Credits =C2=A0. . . . . . . . . . . . . . . . . . . . . . = . . . . . =C2=A07
=C2=A0 4. =C2=A0Metrics =C2=A0. . . . . . . . . . . . . . . . . . . . . . = . . . . . =C2=A07
=C2=A0 5. =C2=A0Extensions to DLEP . . . . . . . . . . . . . . . . . . . .= . . =C2=A08
=C2=A0 6. =C2=A0Normal Session Flow =C2=A0. . . . . . . . . . . . . . . . = . . . . . =C2=A08
=C2=A0 7. =C2=A0Generic DLEP Packet Definition . . . . . . . . . . . . . .= . . =C2=A09
=C2=A0 8. =C2=A0Message Header Format =C2=A0. . . . . . . . . . . . . . . = . . . . . 10
=C2=A0 9. =C2=A0Message TLV Block Format . . . . . . . . . . . . . . . . .= . . 10
=C2=A0 10. DLEP Sub-TLVs =C2=A0. . . . . . . . . . . . . . . . . . . . . .= . . 11
=C2=A0 =C2=A0 10.1. =C2=A0Identification Sub-TLV. . . . . . . . . . . . . = . . . . . 12
=C2=A0 =C2=A0 10.2. =C2=A0DLEP Version Sub-TLV. . . . . . . . . . . . . . = . . . . . 13
=C2=A0 =C2=A0 10.3. =C2=A0Peer Type Sub-TLV . . . . . . . . . . . . . . . = . . . . . 14
=C2=A0 =C2=A0 10.4. =C2=A0MAC Address Sub-TLV . . . . . . . . . . . . . . = . . . . . 14
=C2=A0 =C2=A0 10.5. =C2=A0IPv4 Address Sub-TLV. . . . . . . . . . . . . . = . . . . . 15
=C2=A0 =C2=A0 10.6. =C2=A0IPv6 Address Sub-TLV. . . . . . . . . . . . . . = . . . . . 16
=C2=A0 =C2=A0 10.7. =C2=A0Maximum Data Rate Sub-TLV . . . . . . . . . . . = . . . . . 16
=C2=A0 =C2=A0 10.8. =C2=A0Current Data Rate Sub-TLV . . . . . . . . . . . = . . . . . 17
=C2=A0 =C2=A0 10.9. =C2=A0Latency Sub-TLV . . . . . . . . . . . . . . . . = . . . . . 18
=C2=A0 =C2=A0 10.10. Resources Sub-TLV . . . . . . . . . . . . . . . . . .= . . 18
=C2=A0 =C2=A0 10.11. Expected Forwarding Time Sub-TLV. . . . . . . . . . .= . . 19
=C2=A0 =C2=A0 10.12. Relative Link Quality Sub-TLV . . . . . . . . . . . .= . . 20
=C2=A0 =C2=A0 10.13. Peer Termination Sub-TLV. . . . . . . . . . . . . . .= . . 20
=C2=A0 =C2=A0 10.14. Heartbeat Interval Sub-TLV. . . . . . . . . . . . . .= . . 21
=C2=A0 =C2=A0 10.15. Heartbeat Threshold Sub-TLV . . . . . . . . . . . . .= . . 21
=C2=A0 =C2=A0 10.16. Link Characteristics ACK Timer Sub-TLV. . . . . . . .= . . 22
=C2=A0 =C2=A0 10.17. Credit Window Status Sub-TLV. . . . . . . . . . . . .= . . 23
=C2=A0 =C2=A0 10.18. Credit Grant Sub-TLV. . . . . . . . . . . . . . . . .= . . 24
=C2=A0 =C2=A0 10.19. Credit Request Sub-TLV. . . . . . . . . . . . . . . .= . . 24
=C2=A0 11. =C2=A0DLEP Protocol Messages =C2=A0. . . . . . . . . . . . . . = . . . . . 25
=C2=A0 =C2=A0 11.1. =C2=A0Message Block TLV Values =C2=A0. . . . . . . . .= . . . . . . . 25
=C2=A0 12. =C2=A0Peer Discovery Messages . . . . . . . . . . . . . . . . .= . . 26
=C2=A0 =C2=A0 12.1. =C2=A0Attached Peer Discovery Message . . . . . . . . = . . . . . 26
=C2=A0 =C2=A0 12.2. =C2=A0Detached Peer Discovery Message . . . . . . . . = . . . . . 27
=C2=A0 13. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . = 29
=C2=A0 14. Peer Update Message. . . . . . . . . . . . . . . . . . . . . . = 30
=C2=A0 15. Peer Update ACK Message. . . . . . . . . . . . . . . . . . . . = 31
=C2=A0 16. Peer Termination Message . . . . . . . . . . . . . . . . . . . = 32
=C2=A0 17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . = 33
=C2=A0 18. Neighbor Up Message =C2=A0. . . . . . . . . . . . . . . . . . .= . . 33
=C2=A0 19. Neighbor Up ACK Message. . . . . . . . . . . . . . . . . . . . = 35
=C2=A0 20. Neighbor Down Message =C2=A0. . . . . . . . . . . . . . . . . .= . . 35
=C2=A0 21. Neighbor Down ACK Message. . . . . . . . . . . . . . . . . . . = 36
=C2=A0 22. Neighbor Update Message =C2=A0. . . . . . . . . . . . . . . . .= . . 37

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 2]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 23. Neighbor Address Update Message. . . . . . . . . . . . . . . . = 38
=C2=A0 24. Neighbor Address Update ACK Message. . . . . . . . . . . . . . = 39
=C2=A0 25. Heartbeat Message =C2=A0. . . . . . . . . . . . . . . . . . . .= . . 40
=C2=A0 26. Link Characteristics Message . . . . . . . . . . . . . . . . . = 40
=C2=A0 27. Link Characteristics ACK Message . . . . . . . . . . . . . . . = 42
=C2=A0 28. Security Considerations. . . . . . . . . . . . . . . . . . . . = 43
=C2=A0 29. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . = 43
=C2=A0 =C2=A0 29.1 =C2=A0TLV Registrations. . . . . . . . . . . . . . . . = . . . . . 43
=C2=A0 =C2=A0 29.2 =C2=A0Expert Review: Evaluation Guidelines . . . . . . = . . . . . 43
=C2=A0 =C2=A0 29.3 =C2=A0Message TLV Type Registrations . . . . . . . . . = . . . . . 43
=C2=A0 =C2=A0 29.4 =C2=A0DLEP Order Registrations . . . . . . . . . . . . = . . . . . 44
=C2=A0 =C2=A0 29.5 =C2=A0DLEP Sub-TLV Type Registrations. . . . . . . . . = . . . . . 44
=C2=A0 30. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . = 45

1. Introduction

=C2=A0 There exist today a collection of modem devices that control links = of
=C2=A0 variable bandwidth and quality. Examples of these types of links =C2=A0 include line-of-sight (LOS) radios, satellite terminals, and cable/=
=C2=A0 DSL modems. Fluctuations in speed and quality of these links can =C2=A0 occur due to configuration (in the case of cable/DSL modems), or on= a
=C2=A0 moment-to-moment basis, due to physical phenomena like multipath =C2=A0 interference, obstructions, rain fade, etc. It is also quite possib= le
=C2=A0 that link quality and bandwidth varies with respect to individual =C2=A0 neighbors on a link, and with the type of traffic being sent. As an=
=C2=A0 example, consider the case of an 802.11g access point, serving 2 =C2=A0 associated laptop computers. In this environment, the answer to the=
=C2=A0 question "What is the bandwidth on the 802.11g link?" is = "It depends
=C2=A0 on which associated laptop we're talking about, and on what kin= d of
=C2=A0 traffic is being sent." While the first laptop, being physical= ly
=C2=A0 close to the access point, may have a bandwidth of 54Mbps for
=C2=A0 unicast traffic, the other laptop, being relatively far away, or =C2=A0 obstructed by some object, can simultaneously have a bandwidth of =C2=A0 only 32Mbps for unicast. However, for multicast traffic sent from t= he
=C2=A0 access point, all traffic is sent at the base transmission rate
=C2=A0 (which is configurable, but depending on the model of the access =C2=A0 point, is usually 24Mbps or less).

=C2=A0 In addition to utilizing variable bandwidth links, mobile networks<= br> =C2=A0 are challenged by the notion that link connectivity will come and g= o
=C2=A0 over time. =C2=A0Effectively utilizing a relatively short-lived con= nection
=C2=A0 is problematic in IP routed networks, as routing protocols tend to<= br> =C2=A0 rely on independent timers at OSI Layer 3 to maintain network
=C2=A0 convergence (e.g. HELLO messages and/or recognition of DEAD routing=
=C2=A0 adjacencies). These short-lived connections can be better utilized<= br> =C2=A0 with an event-driven paradigm, where acquisition of a new neighbor<= br> =C2=A0 (or loss of an existing one) is somehow signaled, as opposed to a =C2=A0 timer-driven paradigm.

=C2=A0 Another complicating factor for mobile networks are the different =C2=A0 methods of physically connecting the modem devices to the router. =C2=A0 Modems can be deployed as an interface card in a router's
=C2=A0 chassis, or as a standalone device connected to the router via
=C2=A0 Ethernet, USB, or even a serial link. In the case of Ethernet or

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 3]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 serial attachment, with existing protocols and techniques, routing<= br> =C2=A0 software cannot be aware of convergence events occurring on the
=C2=A0 radio link (e.g. acquisition or loss of a potential routing
=C2=A0 neighbor), nor can the router be aware of the actual capacity of =C2=A0 the link. This lack of awareness, along with the variability in
=C2=A0 bandwidth, leads to a situation where quality of service (QoS)
=C2=A0 profiles are extremely difficult to establish and properly
=C2=A0 maintain. This is especially true of demand-based access schemes =C2=A0 such as Demand Assigned Multiple Access (DAMA) implementations
=C2=A0 used on some satellite systems. With a DAMA-based system,
=C2=A0 additional bandwidth may be available, but will not be used
=C2=A0 unless the network devices emit traffic at rate higher than the
=C2=A0 currently established rate. Increasing the traffic rate does not =C2=A0 guarantee additional bandwidth will be allocated; rather, it may =C2=A0 result in data loss and additional retransmissions on the link.

=C2=A0 In attempting to address the challenges listed above, the authors =C2=A0 have developed the Data Link Exchange Protocol, or DLEP.

=C2=A0 UH> Replace the above sentence with: "In attempting to addr= ess the
challenges listed above, this document specifies the Data Link
Exchange Protocol (DLEP)".

=C2=A0 The DLEP
=C2=A0 protocol runs between a router and its attached modem devices,
=C2=A0 allowing the modem to communicate link characteristics as they
=C2=A0 change, and convergence events (acquisition and loss of potential =C2=A0 routing neighbors). The following diagrams are used to illustrate =C2=A0 the scope of DLEP sessions.

=C2=A0 |-----Local Neighbor-----| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-----= Remote Neighbor----|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 (fa= r-end device) =C2=A0 |

=C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 +-------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+-------+ =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 | Router |=3D=3D=3D=3D=3D=3D=3D| Modem |{~~~~}| Modem |=3D=3D=3D=3D= =3D=3D=3D| Router |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | Device| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Device| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 +-------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+-------+ =C2=A0 =C2=A0 =C2=A0 +--------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 | Link =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-DLEP--| =C2=A0 =C2=A0 =C2=A0 | = Protocol | =C2=A0 =C2=A0 =C2=A0 |-DLEP--|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 | (e.g. =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 | 802.11) =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Figure 1: DLEP Network

=C2=A0 In Figure 1, when a local client (Modem device) detects the
=C2=A0 presence of a remote neighbor, it sends an indication to its
=C2=A0 local router via the DLEP session. Upon receipt of the indication,<= br> =C2=A0 the local router would take appropriate action (e.g. initiation
=C2=A0 of discovery or HELLO protocols) to converge the network. After
=C2=A0 notification of the new neighbor, the modem device utilizes the
=C2=A0 DLEP session to report the characteristics of the link (bandwidth,<= br> =C2=A0 latency, etc) to the router on an as-needed basis.

=C2=A0 DLEP is independent of the underlying link type and topology.
=C2=A0 Figure 2 shows how DLEP can support a configuration whereby
=C2=A0 routers are connected with different link types and with different<= br> =C2=A0 network configurations. In this setup, the routers are connected

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 4]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 with two different devices (Modem device A and Modem device B).
=C2=A0 Modem A is connected via a point-to-point link, whereas Modem B
=C2=A0 is connected via a shared medium. In both cases, the DLEP session =C2=A0 is used to report the characteristics of the link (bandwidth,
=C2=A0 latency, etc.) to network neighbors on an as-needed basis. The
=C2=A0 modem is also able to use the DLEP session to notify the router
=C2=A0 when the remote neighbor is lost, shortening the time required to =C2=A0 re-converge the network.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 +------+ Modem A| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Modem A+-----+
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| Device | =C2=A0<=3D=3D=3D= =3D=3D // =3D=3D=3D=3D=3D=3D> =C2=A0 | Device | =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0= P-t-P Link =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Protocol =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +---+----+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+---+----+
=C2=A0 | Router | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| Router |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 +---+----+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+---+----+
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 +------+ Modem B| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Modem B| =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Device | =C2=A0 o o o o = o o o o =C2=A0 =C2=A0| Device +-----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0o = =C2=A0Shared =C2=A0 o =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 o Medium =C2=A0o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o =C2=A0 =C2=A0 =C2=A0 o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o =C2=A0 =C2=A0 o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o =C2=A0 o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | Modem B|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | Device |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +---+----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +---+----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | Router |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2: DLEP Netw= ork with Multiple Modem Devices

=C2=A0 DLEP exists as a collection of type-length-value (TLV) based messag= es
=C2=A0 using [RFC5444] formatting. The protocol can be used for both Ether= net
=C2=A0 attached modems (utilizing, for example, a UDP socket for transport=
=C2=A0 of the RFC 5444 packets), or in environments where the modem is an<= br> =C2=A0 interface card in a chassis (via a message passing scheme). DLEP =C2=A0 utilizes a session paradigm between the modem device and its
=C2=A0 associated router. If multiple modem devices are attached to a
=C2=A0 router (as in FIgure 2),

=C2=A0 UH> s/FIgure/Figure/

=C2=A0 a separate DLEP session MUST exist for each
=C2=A0 modem. If a modem device supports multiple connections to a router<= br> =C2=A0 (via multiple logical or physical interfaces), or supports
=C2=A0 connections to multiple routers, a separate DLEP session MUST exist=
=C2=A0 for each connection.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

1.1 =C2=A0Requirements

=C2=A0 The key words "MUST", "MUST NOT", "REQUIRE= D", "SHALL", "SHALL NOT",
=C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED"= , "MAY", and "OPTIONAL" in this
=C2=A0 document are to be interpreted as described in BCP 14, RFC 2119
=C2=A0 [RFC2119].

=C2=A0 UH> I think there should be a Terminology and Notation section, = in
particular for importing RFC5444 terminology and notation and to
define terms such as DLEP Server etc.

2. Assumptions

=C2=A0 In order to implement discovery in the DLEP protocol (thereby
=C2=A0 avoiding some configuration), we have defined

=C2=A0 UH> s/we have defined/a first-speaker and a passive-listener sch= eme
is speficied in this document/

=C2=A0 a first-speaker and a
=C2=A0 passive-listener scheme. Borrowing from existing terminology, this<= br> =C2=A0 document refers to the first-speaker as the 'client', and t= he passive
=C2=A0 listener as the 'server', even though there is no client/se= rver
=C2=A0 relationship in the classic sense. In a typical deployment, a route= r
=C2=A0 would appear as the DLEP 'server', and an attached modem de= vice would
=C2=A0 act as the 'client' (e.g. the initiator for discovery).

=C2=A0 DLEP assumes that participating clients appear to the server as a =C2=A0 transparent bridge - specifically, the assumption is that the
=C2=A0 destination MAC address for data traffic in any frame emitted by =C2=A0 the server should be the MAC address of the next-hop router or end-=
=C2=A0 device, and not the MAC address of any of the intervening clients.<= br>
=C2=A0 DLEP assumes that security on the session (e.g. authentication of =C2=A0 session partners, encryption of traffic, or both) is dealt with by<= br> =C2=A0 the underlying transport mechanism for the RFC 5444 packets (e.g. b= y
=C2=A0 using a transport such as DTLS [DTLS]).

=C2=A0 UH> s/[DTLS]/[RFC4347]/

=C2=A0 DLEP utilizes a session-oriented paradigm. There are two classes =C2=A0 of sessions - the first is identified as a 'peer session'. = The
=C2=A0 peer session exists between a DLEP server and a DLEP client. All =C2=A0 DLEP messages between client and server are transmitted within the<= br> =C2=A0 context of the peer session.

=C2=A0 The other type of DLEP session is referred to as a 'neighbor se= ssion'.
=C2=A0 Neighbor sessions can be instantiated by either the DLEP server or<= br> =C2=A0 client, and represent an identifiable destination (i.e. an address)=
=C2=A0 within the network. Examples of a destination would be a unicast =C2=A0 address (for either a next-hop router, or for an end-station), or =C2=A0 a multicast address. A DLEP neighbor session MUST exist for every =C2=A0 destination that exists in the network.

=C2=A0 The optional [RFC5444] message header Sequence Number MUST be
=C2=A0 included in all DLEP packets.

=C2=A0 UH> What is a DLEP packet? There is only an RFC5444 packet, and = I
don't think that DLEP should specify anything about that (there could be other MANET protocol messages contained). Moreover, the message
sequence number MUST be contained in the messages, not the packets.

=C2=A0 Sequence Numbers start at 1 and are
=C2=A0 incremented by one for each original and retransmitted message.

=C2=A0 UH> Why not at 0?

=C2=A0 The
=C2=A0 unsigned 16-bit Sequence Number rolls over at 65535 to 1.

=C2=A0 UH> That should be explained (as done in, e.g., OLSRv2). Define = the
relationship "greater" for rolling-over sequence numbers.

=C2=A0 A
=C2=A0 Sequence Number of 0 is not valid. Sequence Numbers are unique
=C2=A0 within the context of a DLEP session.

=C2=A0 UH> Unique per router?

=C2=A0 Sequence numbers are used in
=C2=A0 DLEP to correlate a response to a request.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 6]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

3. Credits

=C2=A0 DLEP includes an OPTIONAL credit-windowing scheme analogous to the<= br> =C2=A0 one documented in [RFC5578]. In this scheme, traffic between the =C2=A0 DLEP client and the DLEP server is treated as two unidirectional =C2=A0 windows. This document identifies these windows as the "Client=
=C2=A0 Receive Window", or CRW, and the "Server Receive Window&q= uot;, or SRW.

=C2=A0 If credits are used, they MUST be granted by the receiver on a
=C2=A0 given window - that is, on the "Client Receive Window" (C= RW),
=C2=A0 the DLEP client is responsible for granting credits to the server,<= br> =C2=A0 allowing it (the server) to send data to the client. Likewise,
=C2=A0 the DLEP server is responsible for granting credits on the SRW,
=C2=A0 which allows the client to send data to the server.

=C2=A0 DLEP expresses all credit data in number of octets. The total numbe= r
=C2=A0 of credits on a window, and the increment to add to a grant, are =C2=A0 always expressed as a 64-bit unsigned quantity.

=C2=A0 If used, credits are managed on a neighbor session basis; that is,<= br> =C2=A0 separate credit counts are maintained for each neighbor session
=C2=A0 requiring the service. Credits do not apply to DLEP peer sessions.<= br>
4. Metrics

=C2=A0 DLEP includes the ability for the client and server to communicate<= br> =C2=A0 metrics that reflect the characteristics (e.g. bandwidth, latency)<= br> =C2=A0 of the variable-quality link in use. As mentioned in the
=C2=A0 introduction section of this document

=C2=A0 UH> s/As mentioned in the introduction section of this document/= As
mentioned in Section 1/

=C2=A0 , metrics have to be used
=C2=A0 within a context - for example, metrics to a unicast address in
=C2=A0 the network. DLEP allows for metrics to be sent within two
=C2=A0 contexts - neighbor session context (those for a given destination<= br> =C2=A0 within the network), and peer session context (those that apply
=C2=A0 to all destinations accessed via the DLEP client). Metrics
=C2=A0 supplied on DLEP Peer messages are, by definition, in the context =C2=A0 of a peer session; metrics supplied on Neighbor messages are, by =C2=A0 definition, used in the context of a neighbor session.

=C2=A0 Supplying metrics in a peer session context gives clients the
=C2=A0 ability to supply default metrics on a 'device-wide' basis.= It is
=C2=A0 left to implementations to choose sensible default values based on<= br> =C2=A0 their specific characteristics. Additionally, the metrics (either =C2=A0 at a peer or neighbor session context) MAY be used to report non- =C2=A0 changing, or static, metrics. Clients having static link metric
=C2=A0 characteristics SHOULD report metrics only once for a given
=C2=A0 neighbor session (or peer session, if all connections via the clien= t
=C2=A0 are of this static nature).

=C2=A0 The approach of allowing for different contexts for metric data
=C2=A0 increases both the flexibility and the complexity of using metric =C2=A0 data. This document details the mechanism whereby the data is
=C2=A0 transmitted, however, the specific algorithms for utilizing the
=C2=A0 dual-context metrics is out of scope and not addressed by this
=C2=A0 document.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 7]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

5. Extensions to DLEP

=C2=A0 While this draft

=C2=A0 UH> s/draft/document/

=C2=A0 represents the best efforts of the co-authors, and
=C2=A0 the working group, to be functionally complete,

=C2=A0 UH> I would remove that. Just say that future extensions are
supported by DLEP for new functionality, or so.

=C2=A0 it is recognized
=C2=A0 that extensions to DLEP will in all likelihood be necessary as more=
=C2=A0 link types are utilized. To allow for future innovation, the draft<= br> =C2=A0 allocates numbering space for experimental orders and sub-TLVs. DLE= P
=C2=A0 implementations MUST be capable of parsing and acting on the orders=
=C2=A0 and sub-TLVs as documented in this specification. DLEP orders/sub-T= LVs
=C2=A0 in the experimental numbering range SHOULD be silently dropped by a= n
=C2=A0 implementation if they are not understood. The intent of the
=C2=A0 experimental numbering space is to allow for further development of=
=C2=A0 DLEP protocol features and function. If subsequent development yiel= ds
=C2=A0 new features with sufficient applicability, those features should b= e
=C2=A0 either included in an update of this specification, or documented i= n
=C2=A0 a standalone specification.

6. Normal Session Flow

=C2=A0 A session between a client and a server is established by exchangin= g
=C2=A0 the "Peer Discovery" and "Peer Offer" messages = described below.

=C2=A0 The flows described in this document create a state-full protocol =C2=A0 between client and server. Both client and server initialize in a =C2=A0 "discovery" state, and the client issues a "Peer Dis= covery" message.
=C2=A0 When the server receives a Peer Discovery, it responds with a "= ;Peer
=C2=A0 Offer" message, and enters an "in session" state wit= h the client.
=C2=A0 Receipt of the Peer Offer at the client causes it (the client) to =C2=A0 transition into the "in session" state.

=C2=A0 Once that exchange has successfully occurred, messages transferred<= br> =C2=A0 in the context of the peer session will consist of
=C2=A0 o =C2=A0Periodic 'Heartbeat' messages, intended to keep the= peer session
=C2=A0 =C2=A0 =C2=A0alive, and to verify bidirectional connectivity, and/o= r
=C2=A0 o =C2=A0Peer Update messages, indicating some change in status that= one
=C2=A0 =C2=A0 =C2=A0of the peers needs to communicate to the other.

=C2=A0 In addition to the messages above, the peers will transmit DLEP
=C2=A0 messages concerning destinations in the network. These messages
=C2=A0 trigger creation/maintenance/termination of 'neighbor se= ssions'. For
=C2=A0 example, a peer will inform its DLEP partner of the presence of a =C2=A0 new destination via the "Neighbor Up" message. Receipt of= a Neighbor
=C2=A0 Up causes the receiving peer to allocate the necessary resources, =C2=A0 creating a neighbor session, and transition to an "in session&= quot; state
=C2=A0 on the newly created neighbor session. The in-session state persist= s
=C2=A0 until notification of neighbor loss is received, or by optional
=C2=A0 timeout due to inactivity.

=C2=A0 The loss of a destination is communicated via the "Neighbor Do= wn"
=C2=A0 message, and changes in status to the destination (e.g. varying
=C2=A0 link quality, or addressing changes) are communicated via a
=C2=A0 "Neighbor Update" message.

=C2=A0 Again, metrics can be expressed within the context of a neighbor =C2=A0 session via the Neighbor Update message, or within the context of
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 a peer session (reflecting the link as a whole) via the Peer Update=
=C2=A0 message. In cases where metrics are provided on the peer session, t= he
=C2=A0 receiving peer MUST propagate the metrics to all neighbor sessions<= br> =C2=A0 accessed via the peer. A DLEP peer MAY send metrics both in a peer<= br> =C2=A0 session context (via the Peer Update message) and a neighbor sessio= n
=C2=A0 context (via Neighbor Update) at any time. The heuristics for
=C2=A0 applying received peer session and neighbor session metrics is left=
=C2=A0 to implementations.

=C2=A0 In addition to receiving metrics about the link, DLEP provides for<= br> =C2=A0 the ability for a server to request a different amount of bandwidth= ,
=C2=A0 or latency, from the client via the Link Characteristics Message. =C2=A0 This allows the server to deal with requisite increases (or decreas= es)
=C2=A0 of allocated bandwidth/latency in demand-based schemes in a more =C2=A0 deterministic manner.

7. Generic DLEP Packet Definition

=C2=A0 The Generic DLEP Packet Definition follows the format for packets =C2=A0 defined in [RFC5444].

=C2=A0 UH> I don't see why DLEP should define a "DLEP Packet&q= uot;; that seems
against the intended use of RFC5445, where only messages are specific
to a protocol. Limiting the use of the packet restricts RFC5444, and
is also not necessary. In general, for the following sections, I am
not convinced that we need the figures, since TLVs are flexible and
not always the same. I like the way it is done in RFC6130 with the
regex notation. In addition, the fields should use the same notation
as in RFC5444.

=C2=A0 The Generic DLEP Packet Definition contains the following fields:
=C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 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
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 |Version| Flags | Packet Sequence Number =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Packet TLV =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | Block... =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 | Message (Contains DLEP message)... =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

=C2=A0 Version =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Ve= rsion of RFC 5444 specification on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0which the packet/messages/TLVs are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0constructed.

=C2=A0 Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- 4 bit field. All bits MUST be ignored
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0by DLEP implementations.

=C2=A0 Packet Sequence Number - If present, the packet sequence number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0is parsed and ignored. DLEP does NOT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0use or generate packet sequence numbers.

=C2=A0 Packet TLV block =C2=A0 =C2=A0 =C2=A0 - A TLV block which contains = packet level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0TLV information. DLEP implementations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MUST NOT use this TLV block.

=C2=A0 Message =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Th= e packet MAY contain zero or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0messages, however, DLEP messages are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0encoded within an RFC 5444 Message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0TLV Block.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 9]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

8. Message Header Format

=C2=A0 DLEP utilizes the following format for the RFC 5444 message header<= br>
=C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 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
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 | =C2=A0 =C2=A0Msg Type =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLV Block... =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - An 8-bit field wh= ich specifies the type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0of the message. For DLEP, this field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0contains DLEP_MESSAGE (value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1 (bit 3= , mhasseqnum bit is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0set). =C2=A0All other bits are unused and MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0be set to '0'.

UH> Why not just say that a sequence number MUST be included and not
limiting the other fields? Like in RFC6130.

=C2=A0 Message Address Length - A 4-bit unsigned integer field encoding th= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0length of all addresses included in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0message. DLEP implementations do not use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0this field; contents SHOULD be ignored.

UH> That alligns with my concern that Address Blocks are not used.
Anyway, it should be mentioned which value to put in this field when
generating a message.

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - A 16-bit unsigned= integer field which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0specifies the number of octets that make up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the message including the message header.

=C2=A0 Message Sequence Number - A 16-bit unsigned integer field that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 contains a sequence number,

UH> Notation: sequence number or Sequence Number? Same for sub-TLV or Sub-TLV throughout the document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 generated by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 the originator of the message. Sequence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 numbers range from 1 to 65535. Sequence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 numbers roll over at 65535 to 1; 0 is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 invalid.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TLV Bl= ock included in the message.

9. Message TLV Block Format

=C2=A0 The DLEP protocol is organized as a set of orders, each with a
=C2=A0 collection of Sub-TLVs. The Sub-TLVs carry information needed
=C2=A0 to process and/or establish context (e.g. the MAC address of a
=C2=A0 far-end router), and the 'tlv-type' field in the message TL= V
=C2=A0 block carries the DLEP order itself. The DLEP orders are
=C2=A0 enumerated in section 11.1 of this document, and the messages
=C2=A0 created using these orders are documented in sections 12 through =C2=A0 27.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 10]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 DLEP uses the following settings for an RFC 5444 Message TLV
=C2=A0 block:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 TLVs Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0TLV Type =C2=A0 =C2=A0 | TLV Flags =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0Length =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Value... = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLVs Length - A 16-bit unsigned integer field that contains the tot= al
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of octets i= n all of the immediately following
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLV elements (tlvs= -length not included).

=C2=A0 TLV Type =C2=A0 =C2=A0- An 8-bit unsigned integer field specifying = the type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the TLV. DLEP u= ses this field to specify the DLEP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 order. Valid DLEP = orders are defined in section 11.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of this document.<= br>
=C2=A0 TLV Flags =C2=A0 - An 8-bit flags bit field. Bit 3 (thasvalue) MUST= be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set; all other bit= s are not used and MUST be set
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0- Length of the 'Value' field of= the TLV

=C2=A0 Value =C2=A0 =C2=A0 =C2=A0 - A field of length <Length> which= contains data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific to a part= icular TLV type. In the DLEP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case, this field w= ill consist of a collection of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DLEP sub-TLVs appr= opriate for the DLEP action
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specified in the T= LV type field.

10. DLEP sub-TLVs

=C2=A0 DLEP protocol messages are transported in an RFC 5444 message TLV.<= br>
=C2=A0 UH> s/RFC 5444/[RFC5444].

=C2=A0 All DLEP messages use the RFC 5444 DLEP_MESSAGE value (TBD). The =C2=A0 protocol messages consist of a DLEP order, encoded in the 'tlv-= type'
=C2=A0 field in the message TLV block, with the 'value' field of t= he TLV
=C2=A0 block containing a collection (1 or more) DLEP sub-TLVs.

=C2=A0 The format of DLEP Sub-TLVs is consistent with RFC 5444 in that the=
=C2=A0 Sub-TLVs contain a flag field in addition to the type, length, and<= br> =C2=A0 value fields. Valid DLEP Sub-TLVs are:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLV =C2=A0 =C2=A0 =C2=A0TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Value =C2=A0 =C2=A0Description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Identification s= ub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0DLEP Version sub= -TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Peer Type sub-TL= V
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0MAC Address sub-= TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0IPv4 Address sub= -TLV

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 11]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0IPv6 Address sub= -TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Maximum Data Rat= e (MDR) sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Current Data Rat= e (CDR) sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Latency sub-TLV<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Resources sub-TL= V
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Expected Forward= ing Time (ETX) sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Relative Link Qu= ality (RLQ) sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Status sub-TLV
UH> Does not correspond with Table of Contents

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Heartbeat Interv= al sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Heartbeat Thresh= old sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor down AC= K timer sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Link Characteris= tics ACK timer sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Credit Window St= atus sub-TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Credit Grant sub= -TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Credit Request s= ub-TLV

=C2=A0 DLEP sub-TLVs contain the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0TLV Type =C2=A0 =C2=A0 |TLV Flags=3D0x10 | Length =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Value... =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0- An 8-bit unsigned integer field specifying = the type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the sub-TLV.
UH> shouldn't that be "Sub-TLV Type" and "Sub-TLV fla= gs"?

=C2=A0 TLV Flags =C2=A0 - An 8-bit flags bit field. Bit 3 (thasvalue) MUST= be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set, all other bit= s are not used and MUST be set to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0- An 8-bit length of the value field of = the sub-TLV

=C2=A0 Value =C2=A0 =C2=A0 =C2=A0 - A field of length <Length> which= contains data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific to a part= icular sub-TLV.

10.1 =C2=A0Identification Sub-TLV

=C2=A0 This Sub-TLV MUST exist in the TLV Block for all DLEP messages, and=
=C2=A0 MUST be the first Sub-TLV of the message. Further, there MUST be ON= LY
=C2=A0 one Identification Sub-TLV in an RFC 5444 message TLV block. The =C2=A0 Identification sub-TLV contains client and server identification =C2=A0 information used to establish the proper context for processing DLE= P
=C2=A0 protocol messages.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 12]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The Identification sub-TLV contains the following fields:

=C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 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
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 |TLV Type =3D TBD |TLV Flags=3D0x10 |Length =3D 8 =C2=A0 =C2=A0 | S= erver ID =C2=A0 =C2=A0 |
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Server ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Client ID =C2=A0 =C2=A0 |
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Client ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0- Value TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 - 0x10, Bit 3 (thasvalue) is set, all other= bits are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unused and = MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0- 8

=C2=A0 Server ID =C2=A0 =C2=A0 - Indicates the Server ID of the DLEP sessi= on.

=C2=A0 Client ID =C2=A0 =C2=A0 - indicates the Client ID of the DLEP sessi= on.

=C2=A0 When the client initiates discovery (via the Peer Discovery message= ),
=C2=A0 it MUST set the Client ID to a 32-bit quantity that will be used to=
=C2=A0 uniquely identify this session from the client-side. The client MUS= T
=C2=A0 set the Server ID to '0'. When responding to the Peer Disco= very
=C2=A0 message, the server MUST echo the Client ID, and MUST supply its ow= n
=C2=A0 unique 32-bit quantity to identify the session from the server'= s
=C2=A0 perspective. After the Peer Discovery/Peer Offer exchange, both the=
=C2=A0 Client ID and the Server ID MUST be set to the values obtained from=
=C2=A0 the Peer DIscovery/Peer Offer sequence.

UH> s/DIscovery/Discovery/

10.2 =C2=A0DLEP Version Sub-TLV

=C2=A0 The DLEP Version Sub-TLV is an OPTIONAL TLV in both the Peer
=C2=A0 Discovery and Peer Offer messages. The Version Sub-TLV is used to =C2=A0 indicate the client or server version of the protocol. The client =C2=A0 and server MAY use this information to decide if the peer is runnin= g
=C2=A0 at a supported level.

=C2=A0 The DLEP Version Sub-TLV contains the following fields:

=C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 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
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 |TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length=3D4 =C2=A0 =C2=A0 = =C2=A0 | Major Version |
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
=C2=A0 | Major Version | =C2=A0 =C2=A0 =C2=A0 Minor Version =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0- TBD

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 13]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 TLV Flags =C2=A0 =C2=A0 - 0x10, Bit 3 (thasvalue) is set, all other= bits are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not used an= d MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0- Length is 4

=C2=A0 Major Version - Major version of the client or router protocol.

=C2=A0 Minor Version - Minor version of the client or router protocol.

=C2=A0 Support of this draft

=C2=A0 UH> s/draft/document/

=C2=A0 is indicated by setting the Major Version
=C2=A0 to '1', and the Minor Version to '2' (e.g. Version = 1.2).

10.3 =C2=A0Peer Type Sub-TLV

=C2=A0 The Peer Type Sub-TLV is used by the server and client to give
=C2=A0 additional information as to its type. It is an OPTIONAL sub-TLV in=
=C2=A0 both the Peer Discovery Message and the Peer Offer message. The pee= r
=C2=A0 type is a string and is envisioned to be used for informational
=C2=A0 purposes (e.g. as output in a display command).

=C2=A0 The Peer Type sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length=3D peer =C2=A0 |Pee= r Type Str =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |type string len|Max Len =3D 80 =C2=A0 |=
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Length of peer type str= ing (80 bytes maximum).

=C2=A0 Peer Type String - Non-Null terminated peer type string, maximum =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0length of 80 bytes. For example, a satellite
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0modem might set this variable to 'Satellite
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0terminal'.

10.4 =C2=A0MAC Address Sub-TLV

=C2=A0 The MAC address Sub-TLV MUST appear in all neighbor-oriented
=C2=A0 messages (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbo= r
=C2=A0 Down ACK, Neighbor Update, Link Characteristics Request, and Link =C2=A0 Characteristics ACK). The MAC Address sub-TLV contains the address<= br> =C2=A0 of the far-end (neighbor) destination, and may be either a physical=
=C2=A0 or a virtual destination. Examples of a virtual destination would =C2=A0 be a multicast MAC address, or the broadcast MAC (0xFFFFFFFFFFFF).<= br>

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 14]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The MAC Address sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 6 =C2=A0 =C2=A0= |MAC Address =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0MAC Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| MAC Address =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0- TBD

=C2=A0 TLV Flags =C2=A0 - 0x10, Bit 3 (thasvalue) is set, all other bits a= re not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used and MUST be s= et to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0- 6

=C2=A0 MAC Address - MAC Address of the destination (either physical or =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 virtual).

UH> Are MAC Addresses of different length supported? (e.g. for IEEE 802.= 15.4)

10.5 =C2=A0IPv4 Address Sub-TLV

=C2=A0 The IPv4 Address Sub-TLV MAY be used in Neighbor Up, Neighbor
=C2=A0 Update, and Peer Update Messages, if the client is aware of the
=C2=A0 Layer 3 address. When included in Neighbor messages, the IPv4
=C2=A0 Address sub-TLV contains the IPv4 address of the far-end neighbor.<= br> =C2=A0 In the Peer Update message, it contains the IPv4 address of the
=C2=A0 sending peer. In either case, the sub-TLV also contains an
=C2=A0 indication of whether this is a new or existing address, or is a =C2=A0 deletion of a previously known address.

=C2=A0 The IPv4 Address Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 5 =C2=A0 =C2=A0= | =C2=A0 Add/Drop =C2=A0 =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 Indicator =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0IPv4 Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is set, all other = bits are not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used and MUS= T be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 - 5

=C2=A0 Add/Drop =C2=A0 =C2=A0 - Value indicating whether this is a new or = existing
=C2=A0 Indicator =C2=A0 =C2=A0 =C2=A0address (0x01), or a withdrawal of an= address (0x02).

=C2=A0 IPv4 Address - IPv4 Address of the far-end neighbor or peer.
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

10.6 =C2=A0IPv6 Address Sub-TLV

=C2=A0 The IPv6 Address Sub-TLV MAY be used in Neighbor Up, Neighbor
=C2=A0 Update, and Peer Update Messages, if the client is aware of the
=C2=A0 Layer 3 address. When included in Neighbor messages, the IPv6
=C2=A0 Address sub-TLV contains the IPv6 address of the far-end neighbor.<= br> =C2=A0 In the Peer Update, it contains the IPv6 address of the
=C2=A0 originating peer. In either case, the sub-TLV also contains an
=C2=A0 indication of whether this is a new or existing address, or is a =C2=A0 deletion of a previously known address.

=C2=A0 The IPv6 Address sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 17 =C2=A0 =C2= =A0| =C2=A0 Add/Drop =C2=A0 =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 Indicator =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0IPv6 Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0IPv6 Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0IPv6 Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0IPv6 Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is set, all other = bits are not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used and MUS= T be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 - 17

=C2=A0 Add/Drop =C2=A0 =C2=A0 - Value indicating whether this is a new or<= br> =C2=A0 Indicator =C2=A0 =C2=A0 =C2=A0existing address (0x01), or a withdra= wal of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an address (= 0x02).

=C2=A0 IPv6 Address - IPv6 Address of the far-end neighbor or peer.

10.7 =C2=A0Maximum Data Rate Sub-TLV

=C2=A0 The Maximum Data Rate (MDR) Sub-TLV is used in Neighbor Up, Neighbo= r
=C2=A0 Update, Peer Discovery, Peer Update, and Link Characteristics ACK =C2=A0 Messages to indicate the maximum theoretical data rate, in bits per=
=C2=A0 second, that can be achieved on the link. When metrics are reported=
=C2=A0 via the messages listed above, the maximum data rate MUST be report= ed.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 16]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The Maximum Data Rate sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 8 =C2=A0 =C2=A0= | =C2=A0MDR (bps) =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0MDR (bps) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0MDR (bps) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0TB= D

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A00x10, B= it 3 (thasvalue) is set, all other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0bits are not used and MUST be set to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2= =A08

=C2=A0 Maximum Data Rate =C2=A0 =C2=A0 - =C2=A0A 64-bit unsigned number, r= epresenting the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0maximum theoretical data rate, in bits per
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0second (bps), that can be achieved on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0link.

UH> Why bps and not kbps? 64-bit seems large then.

10.8 =C2=A0Current Data Rate Sub-TLV

=C2=A0 The Current Data Rate (CDR) Sub-TLV is used in Neighbor Up, Neighbo= r
=C2=A0 Update, Peer Discovery, Peer Update, Link Characteristics Request,<= br> =C2=A0 and Link Characteristics ACK messages to indicate the rate at which=
=C2=A0 the link is currently operating, or in the case of the Link
=C2=A0 Characteristics Request, the desired data rate for the link.

=C2=A0 The Current Data Rate sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 8 =C2=A0 =C2=A0= |CDR (bps) =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0CDR (bps) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0CDR (bps) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0TB= D

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A00x10, B= it 3 (thasvalue) is set, all other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0bits are not used and MUST be set to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2= =A08

=C2=A0 Current Data Rate =C2=A0 =C2=A0 - =C2=A0A 64-bit unsigned number, r= epresenting the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0current rate, in bits per second (bps),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0on the link. When reporting metrics (e.g,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0in Neighbor Up, Neighbor Down, Peer
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 17]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Discovery, Peer Update, or Link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Characteristics ACK), if there is no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0distinction between current and maximum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0data rates, current data rate SHOULD be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0set equal to the maximum data rate.

10.9 =C2=A0Expected Forwarding Time Sub-TLV

=C2=A0 The Expected Forwarding Time (EFT) Sub-TLV is used in Neighbor Up,<= br> =C2=A0 Neighbor Update, Peer Discovery, and Peer Update messages to indica= te
=C2=A0 the typical latency between the arrival of a given packet at the =C2=A0 transmitting device and the reception of the packet at the other en= d
=C2=A0 of the link. EFT combines transmission time, idle time, waiting tim= e,
=C2=A0 freezing time, and queuing time to the degree that those values are=
=C2=A0 meaningful to a given transmission medium.

=C2=A0 The Expected Forwarding Time sub-TLV contains the following fields:=

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 4 =C2=A0 =C2=A0= | =C2=A0 EFT (ms) =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0EFT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0TB= D

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A00x10, B= it 3 (thasvalue) is set, all other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0bits are not used and MUST be set to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2= =A04

=C2=A0 UH> Couldn't the length be flexible? To allow shorter/longer= values?

=C2=A0 Current Data Rate =C2=A0 =C2=A0 - =C2=A0A 32-bit unsigned number, r= epresenting the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0expected forwarding time, in milliseconds,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0on the link.

10.10 =C2=A0Latency Sub-TLV

=C2=A0 The Latency Sub-TLV is used in Neighbor Up, Neighbor Update, Peer =C2=A0 Discovery, Peer Update, Link Characteristics Request, and Link
=C2=A0 Characteristics ACK messages to indicate the amount of latency on =C2=A0 the link, or in the case of the Link Characteristics Request, to =C2=A0 indicate the maximum latency required (e.g. a should-not-exeed valu= e)
=C2=A0 on the link.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 18]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The Latency Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 2 =C2=A0 =C2=A0= |Latency (ms) =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|Latency (ms) =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0TB= D

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A00x10, B= it 3 (thasvalue) is set, all other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0bits are not used and MUST be set to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2= =A02

=C2=A0 Latency =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0Th= e transmission delay that a packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0encounters as it is transmitted over the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0link. In Neighbor Up, Neighbor Update,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0and Link Characteristics ACK, this value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0is reported in absolute delay, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0milliseconds. The calculation of latency
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0is implementation dependent. For example,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the latency may be a running average
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0calculated from the internal queuing. If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0a device cannot calculate latency, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0SHOULD be reported as 0. In the Link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Characteristics Request Message, this value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0represents the maximum delay, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0milliseconds, expected on the link.

10.11 =C2=A0Resources Sub-TLV

=C2=A0 The Resources Sub-TLV is used in Neighbor Up, Neighbor Update, Peer=
=C2=A0 Discovery, Peer Update, and Link Characteristics ACK messages to =C2=A0 indicate a percentage (0-100) amount of resources (e.g. battery
=C2=A0 power) remaining on the originating peer.

=C2=A0 The Resources TLV contains the following fields:
=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 1 =C2=A0 =C2=A0= | =C2=A0 Resources =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0TB= D

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A00x10, B= it 3 (thasvalue) is set, all other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0bits are not used and MUST be set to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2= =A01

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 19]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Resources =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0A perce= ntage, 0-100, representing the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0amount of remaining resources, such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0battery power. If resources cannot be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0calculated, a value of 100 SHOULD be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0reported.

UH> Using values between 0-100 wastes values 101-255. Couldn't one u= se
a normalized value between 0-1, represented by values 0-255?

10.12 =C2=A0Relative Link Quality Sub-TLV

=C2=A0 The Relative Link Quality (RLQ) Sub-TLV is used in Neighbor Up,
=C2=A0 Neighbor Update, Peer Discovery, Peer Update, and Link
=C2=A0 Characteristics ACK messages to indicate the quality of the link =C2=A0 as calculated by the originating peer.

=C2=A0 The Relative Link Quality sub-TLV contains the following fields:
=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 1 =C2=A0 =C2=A0= |Relative Link =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |Quality (RLQ) =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0TB= D

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A00x10, B= it 3 (thasvalue) is set, all other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0bits are not used and MUST be set to '0'.
=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2= =A01

=C2=A0 Relative Link Quality - =C2=A0A non-dimensional number, 0-100,

UH> s/number/unsigned integer/ =C2=A0(same for other sections)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0representing relative link quality. A value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0of 100 represents a link of the highest
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0quality. If the RLQ cannot be calculated, a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0value of 100 SHOULD be reported.

10.13 =C2=A0Status Sub-TLV

=C2=A0 The Status Sub-TLV is sent from either the client or server to
=C2=A0 indicate the success or failure of a given request

=C2=A0 The Status Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 1 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 Code =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are not used and MUST be set to '0'.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 20]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 1

=C2=A0 Termination Code - 0 =3D Success
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Non-zero =3D Failure. Specific values of a non-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0zero termination code depend on the operation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0requested (e.g. Neighbor Up, Neighbor Down, etc).

10.14 =C2=A0Heartbeat Interval Sub-TLV

=C2=A0 The Heartbeat Interval Sub-TLV MAY be sent from the client during =C2=A0 Peer Discovery to indicate the desired Heartbeat timeout window. =C2=A0 If included in the Peer Discovery, the server MUST either accept th= e
=C2=A0 timeout interval, or reject the Peer Discovery. Failing to include<= br> =C2=A0 the Heartbeat Interval Sub-TLV in Peer Discovery indicates a
=C2=A0 desire to establish the peer-to-peer DLEP session without an
=C2=A0 activity timeout (e.g. an infinite timeout value).

=C2=A0 The Heartbeat Interval Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 1 =C2=A0 =C2=A0= | Interval =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 1

=C2=A0 Interval =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 0 =3D Do NOT use heartbeats = on this peer-to-peer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0session. Non-zero =3D Interval, in seconds, for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0heartbeat messages.

UH> Is "seconds" an appropriate interval? Same for following s= ections.
No fractions of seconds supported? One could use a structure similar
to the TimeTLV.

10.15 =C2=A0Heartbeat Threshold Sub-TLV

=C2=A0 The Heartbeat Threshold Sub-TLV MAY be sent from the client during<= br> =C2=A0 Peer Discovery to indicate the desired number of windows, of time =C2=A0 (Heartbeat Interval) seconds, to wait before either peer declares =C2=A0 the peer session lost. In this case, the overall amount of time
=C2=A0 before a peer session is declared lost is expressed as
=C2=A0 (Interval * Threshold), where 'Interval' is the value in th= e
=C2=A0 Heartbeat Interval sub-TLV, documented above. If this sub-TLV is =C2=A0 included by the client in the Peer Discovery, the client MUST also<= br> =C2=A0 specify the Heartbeat Interval sub-TLV with a non-zero interval. If=
=C2=A0 this sub-TLV is received during Peer Discovery, the server MUST
=C2=A0 either accept the threshold, or reject the Peer Discovery. If the =C2=A0 Heartbeat Interval Sub-TLV is included, but this Sub-TLV is
=C2=A0 omitted, then a threshold of '1' is assumed.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 21]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The Heartbeat Threshold Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 1 =C2=A0 =C2=A0= | Threshold =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 1

=C2=A0 Threshold =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0 =3D Do NOT use heartbeats = on this peer-to-peer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0session. Non-zero =3D Number of windows, of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Heartbeat Interval seconds, to wait before
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0declaring a peer-to-peer session to be lost.

10.16 =C2=A0Link Characteristics ACK Timer Sub-TLV

=C2=A0 The Link Characteristic ACK Timer Sub-TLV MAY be sent from the
=C2=A0 client during Peer Discovery to indicate the desired number of
=C2=A0 seconds the server should wait for a response to a Link
=C2=A0 Characteristics Request. If this sub-TLV is received during Peer =C2=A0 Discovery, the server MUST either accept the timeout value, or
=C2=A0 reject the Peer Discovery. If this Sub-TLV is omitted,
=C2=A0 implementations SHOULD choose a default value.

=C2=A0 The Link Characteristics ACK Timer Sub-TLV contains the
=C2=A0 following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 1 =C2=A0 =C2=A0= | Interval =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 1

=C2=A0 Interval =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 0 =3D Do NOT use timeouts fo= r Link Characteristics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0requests on this peer-to-peer session.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Non-zero =3D Interval, in seconds, to wait before
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0considering a Link Characteristics Request has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0been lost.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 22]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

10.17 =C2=A0Credit Window Status Sub-TLV

=C2=A0 The Credit Window Status Sub-TLV MUST be sent by the DLEP peer
=C2=A0 originating a Neighbor Up message when use of credits is desired =C2=A0 for a given session. In the Neighbor Up message, when credits
=C2=A0 are desired, the originating peer MUST set the value of the
=C2=A0 window it controls (e.g. the Client Receive Window, or Server
=C2=A0 Receive Window) to an initial, non-zero value. The peer receiving =C2=A0 a Neighbor Up message with a Credit Window Status Sub-TLV MUST
=C2=A0 either reject the use of credits, via a Neighbor Up ACK response =C2=A0 with the correct Status Sub-TLV, or set the initial value from
=C2=A0 the data contained in the Credit Window Status Sub-TLV. If the
=C2=A0 initialization completes successfully, the receiving peer MUST
=C2=A0 respond to the Neighbor Up message with a Neighbor Up ACK message =C2=A0 that contains a Credit Window Status Sub-TLV, initializing its
=C2=A0 receive window.

=C2=A0 The Credit Window Status Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 16 =C2=A0 =C2= =A0| Client Receive|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | Window value =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client Rece= ive Window Value =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0Client Receive Window Value =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Server Receive|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | Window Value =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server Rece= ive Window Value =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0Server Receive Window Value =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 16

=C2=A0 Client Receive =C2=A0 - A 64-bit unsigned number, indicating the =C2=A0 Window value =C2=A0 =C2=A0 =C2=A0 current (or initial) number of cr= edits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0available on the Client Receive Window.

=C2=A0 Server Receive =C2=A0 - A 64-bit unsigned number, indicating the =C2=A0 Window Value =C2=A0 =C2=A0 =C2=A0 current (or initial) number of cr= edits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0available on the Server Receive Window.

UH> Why so large values for both?

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 23]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

10.18 =C2=A0Credit Grant Sub-TLV

=C2=A0 The Credit Grant Request Sub-TLV MAY be sent from either DLEP
=C2=A0 peer to grant an increment to credits on a window. The Credit
=C2=A0 Grant Sub-TLV is sent as part of a Neighbor Update message. The
=C2=A0 value in a Credit Grant Sub-TLV represents an increment to be
=C2=A0 added to any existing credits available on the window. Upon
=C2=A0 successful receipt and processing of a Credit Grant Sub-TLV, the =C2=A0 receiving peer SHOULD respond with a DLEP Neighbor Update message =C2=A0 containing a Credit Window Status Sub-TLV to report the updated
=C2=A0 aggregate values for synchronization purposes.

=C2=A0 The Credit Grant Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 8 =C2=A0 =C2=A0= | Credit =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | Increment =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Credit Increment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Credit Increment =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 0

UH> should be 8

=C2=A0 Reserved =C2=A0 =C2=A0 =C2=A0 =C2=A0 - A 64-bit unsigned number rep= resenting the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0additional credits to be assigned to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0credit window. Since credits can only be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0granted by the receiver on a window, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0applicable credit window (either the CRW or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0the SRW) is derived from the sender of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0grant. The Credit Increment MUST NOT cause
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0the window to overflow; if this condition
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0occurs, implementations MUST set the credit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0window to the maximum value contained in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A064-bit quantity.

10.19 =C2=A0Credit Request Sub-TLV

=C2=A0 The Credit Request Sub-TLV MAY be sent from either DLEP peer, via =C2=A0 a Neighbor Update order, to indicate the desire for the partner to<= br> =C2=A0 grant additional credits in order for data transfer to proceed on =C2=A0 the session. If the corresponding Neighbor Up message for this
=C2=A0 session did NOT contain a Credit Window Status Sub-TLV, indicating<= br> =C2=A0 that credits are to be used on the session, then the Credit Request=
=C2=A0 Sub-TLV MUST be rejected, by sending a Neighbor Update ACK containi= ng
=C2=A0 a Status Sub-TLV, by the receiving peer. If credits are in use on
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 24]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 the session, then the receiving peer MAY respond with a DLEP
=C2=A0 Neighbor Update message containing a Credit Grant Sub-TLV with
=C2=A0 an increment of credits for the session.

=C2=A0 The Credit Request Sub-TLV contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3DTBD =C2=A0|TLV Flags=3D0x10 |Length =3D 0 =C2=A0 =C2=A0= | Reserved, MUST|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | be set to 0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 TLV Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TBD

=C2=A0 TLV Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x10, Bit 3 (thasvalue) is s= et, all other bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are not used and MUST be set to '0'.

=C2=A0 Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 0

UH> should be 1

=C2=A0 Reserved =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 0 =3D This field is currentl= y unused and MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0set to 0.

11. DLEP Protocol Messages

=C2=A0 DLEP places no additional requirements on the RFC 5444 Packet
=C2=A0 formats, or the packet header. DLEP does require that the optional<= br> =C2=A0 'msg-seq-num' in the message header exist, and defines a se= t of
=C2=A0 values for the 'tlv-type' field in the RFC 5444 TLV block. = Therefore,
=C2=A0 a DLEP message, starting from the RFC 5444 Message header, would =C2=A0 appear as follows:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0| TLV block length (length of =C2=A0 |
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DLEP order + Sub-TLVs) =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Message =C2=A0|TLV Flags=3D0x10 | Length =C2=A0 =C2=A0 =C2=A0= =C2=A0| Start of DLEP |
=C2=A0| Block value =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sub-TLVs... =C2=A0= |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

11.1 =C2=A0Message Block TLV Values

=C2=A0 As mentioned above,

UH> reference section

=C2=A0 all DLEP messages utilize a single RFC 5444

UH> [RFC5444]

=C2=A0 message type, the DLEP_MESSAGE (TBD). DLEP further identifies
=C2=A0 protocol messages by using the 'tlv-type' field in the RFC = 5444
=C2=A0 message TLV block. DLEP defines the following Message-Type-
=C2=A0 specific values for the tlv-type field:

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 25]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLV =C2=A0 =C2=A0 =C2=A0TLV
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Value =C2=A0 =C2=A0Description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Attached Peer Di= scovery
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Detached Peer Di= scovery
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Peer Offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Peer Update
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Peer Update ACK<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Peer Termination=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Peer Termination= ACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Up ACK<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Down =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Down AC= K
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Update<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Address= Update
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Neighbor Address= Update ACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Heartbeat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Link Characteris= tics Request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TBD =C2=A0 =C2=A0 =C2=A0Link Characteris= tics ACK

=C2=A0 In all of the diagrams following, the message layouts begin with th= e
=C2=A0 RFC 5444 message header.

12. Peer Discovery Messages

=C2=A0 There are two different types of Peer Discovery Messages, Attached<= br> =C2=A0 and Detached. =C2=A0Attached Peer Discovery Messages are sent by th= e
=C2=A0 client when it is directly attached to the server (e.g. the client<= br> =C2=A0 exists as a card in the chassis, or it is connected via Ethernet wi= th
=C2=A0 no intervening devices). The Detached Peer Discovery message, on th= e
=C2=A0 other hand, is sent by a "remote" client -- for example, = a client at
=C2=A0 a satellite hub system might use a Detached Discovery Message in =C2=A0 order to act as a proxy for remote ground terminals. To explain in<= br> =C2=A0 another way, a detached client uses the variable link itself (the =C2=A0 radio or satellite link) to establish a DLEP session with a remote<= br> =C2=A0 server.

12.1 =C2=A0Attached Peer Discovery Message

=C2=A0 The Attached Peer Discovery Message is sent by an attached client =C2=A0 to a server to begin a new DLEP association. The Peer Offer message=
=C2=A0 is required to complete the discovery process. The client MAY
=C2=A0 implement its own retry heuristics in the event it (the client)
=C2=A0 determines the Attached Peer Discovery Message has timed out. An =C2=A0 Attached Peer Discovery Message received from a peer that is alread= y
=C2=A0 in session MUST be processed as if a Peer Termination Message had =C2=A0 been received. An implementation MAY then process the received
=C2=A0 Attached Peer Discovery Message.

=C2=A0 Note that metric Sub-TLVs MAY be supplied with the Peer Discovery =C2=A0 order. If metric Sub-TLVs are supplied, they MUST be used as a
=C2=A0 default value for all neighbor sessions established via this peer.<= br>
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 26]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The Attached Peer Discovery Message contains the following fields:<= br>
=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLV =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Attached |TLV Flags=3D0x10 | Length =3D11 + =C2=A0| Sub-TLVs = =C2=A0 =C2=A0 =C2=A0|
=C2=A0| Peer Discovery| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= opt sub-TLVs =C2=A0| as noted below|
=C2=A0| (Value TDB) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0- DLEP_MESSAGE (value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - Set to 0x1 (bit 3, mhasseqnum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bit is set). =C2=A0No = other bits are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used and MUST be set t= o '0'.

=C2=A0 Message Address Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x0

UH> consistent way of writing 0 or 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0- 22 + size of optional sub-TLVs

=C2=A0 Message Sequence Number =C2=A0 =C2=A0 =C2=A0 =C2=A0 - A 16-bit unsi= gned integer field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 containing a sequence = number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 generated by the messa= ge
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 originator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - TLVs Length: 14 + size of optional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs.

=C2=A0 Sub-TLVs:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification (MANDAT= ORY)

UH> MANDATORY does not exist in RFC2119

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peer Type (OPTIONAL) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Heartbeat Interval (OP= TIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Heartbeat Threshold (O= PTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Link Characteristics A= CK Timer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maximum Data Rate (OPT= IONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current Data Rate (OPT= IONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Latency (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expected Forwarding Ti= me (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resources (OPTIONAL) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Relative Link Quality = (OPTIONAL)

12.2 =C2=A0Detached Peer Discovery Message

=C2=A0 The Detached Peer Discovery Message is sent by a detached client =C2=A0 proxy to a server to begin a new DLEP session. The Peer Offer
=C2=A0 message is required to complete the discovery process. The client
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 27]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 MAY implement its own retry heuristics in the event it (the client)=
=C2=A0 determines the Detached Peer Discovery Message has timed out. When<= br> =C2=A0 a DLEP implementation responds to a Detached Discovery Message with=
=C2=A0 a Peer Offer, the implementation MUST enter an "in session&quo= t; state
=C2=A0 with the peer. Any subsequent discovery message received from the =C2=A0 peer MUST be processed as if a Peer Termination Message had been =C2=A0 received (e.g. the existing peer session MUST be terminated). An =C2=A0 implementation MAY then process the received discovery message.

=C2=A0 If metric sub-TLVs (e.g. Maximum Data Rate) are supplied with the =C2=A0 Detached Peer Discovery message, these metrics MUST be used as the<= br> =C2=A0 initial values for all far-end sessions (neighbors) established via=
=C2=A0 the peer.

=C2=A0 The Detached Peer Discovery Message contains the following fields:<= br>
=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLV =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Detached |TLV Flags=3D0x10 | Length =3D 11 + | Sub-TLVs as = =C2=A0 |
=C2=A0| Peer Discovery| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0| (Value TDB) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- DLEP_MESSAGE (value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Set to 0x1 (bit 3,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mhasseqnum bit is set).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 All other bits are not used =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and MUST be set to '0'= ;.

=C2=A0 Message Address Length =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- 22 + size of optional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sub-TLVs

=C2=A0 Message Sequence Number =C2=A0 =C2=A0 =C2=A0 - A 16-bit unsigned in= teger
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 field containing a sequence =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number, generated by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message originator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - TLVs Length: 14 + size of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0optional sub-TLVs.

=C2=A0 Sub-TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification (MANDATORY) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peer Type (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Heartbeat Interval (OPTIONAL)=

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 28]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Heartbeat Threshold (OPTIONAL= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Link Char. ACK Timer (OPTIONA= L)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maximum Data Rate (OPTIONAL)<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current Data Rate (OPTIONAL)<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Latency (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expected Forwarding Time (OPT= IONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resources (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Relative Link Quality (OPTION= AL)

=C2=A0 As in the Attached Peer Discovery, the client MAY include metric =C2=A0 sub-TLVs. If included, the router SHOULD use these values as defaul= ts
=C2=A0 that will apply to all sessions established via this client.

13. Peer Offer Message

=C2=A0 The Peer Offer Message is sent by a server to a client in response<= br> =C2=A0 to a Peer Discovery Message. The Peer Offer Message is the response=
=C2=A0 to either of the Peer Discovery messages (Attached or Detached), =C2=A0 and completes the DLEP peer session establishment. Upon sending the=
=C2=A0 Peer Offer Message, the server then enters an "in session"= ; state
=C2=A0 with the client. From the client perspective, receipt and successfu= l
=C2=A0 parsing of a Peer Offer order MUST cause the client to enter the &q= uot;in
=C2=A0 session" state. Any subsequent Discovery messages sent or rece= ived
=C2=A0 on this session MUST be considered an error, and the session MUST b= e
=C2=A0 terminated as if a Peer Termination Message had been received.

=C2=A0 The Peer Offer Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLV =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|DLEP Peer Offer|TLV Flags=3D0x10 | Length =3D 11 + | Sub-TLVs as = =C2=A0 |
=C2=A0| (Value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | opt sub-TLVs =C2=A0| indicated =C2=A0 =C2=A0 |
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | below =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DLEP_MESSAG= E (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Set to 0x1 (bit = 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 22 + size o= f optional sub-TLVs

=C2=A0 Message Sequence Number - A 16-bit unsigned integer field containin= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 a sequence number, generated by the message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 originator.
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 29]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TLV Le= ngth: 14 + size of optional sub-TLVs

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Peer Type (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 IPv4 Address (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Address (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Status (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Heartbeat Interval (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Heartbeat Threshold (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Link Characteristics ACK Timer (OPTIONAL)

14. Peer Update Message

=C2=A0 The Peer Update message is sent by a DLEP peer to indicate local =C2=A0 Layer 3 address changes, or for metric changes on a device-wide
=C2=A0 basis. For example, addition of an IPv4 address to the server would=
=C2=A0 prompt a Peer Update message to its attached DLEP clients. Also, a<= br> =C2=A0 client that changes its Maximum Data Rate for all destinations MAY<= br> =C2=A0 reflect that change via a Peer Update Message to its attached serve= r.

=C2=A0 With Layer 3 address changes, if the client is capable of
=C2=A0 understanding and forwarding this information, the address update =C2=A0 would prompt any remote DLEP clients (DLEP clients that are on the<= br> =C2=A0 far-end of the variable link) to issue a "Neighbor Update"= ; message to
=C2=A0 their local servers with the new (or deleted) addresses. Clients th= at
=C2=A0 do not track Layer 3 addresses MUST silently parse and ignore the P= eer
=C2=A0 Update Message. Clients that track Layer 3 addresses MUST acknowled= ge
=C2=A0 the Peer Update with a Peer Update ACK message. Servers receiving a=
=C2=A0 Peer Update with metric changes MUST apply the new metric to all =C2=A0 neighbor sessions established via the client. Peers MAY employ
=C2=A0 heuristics to retransmit Peer Update messages. The sending of Peer<= br> =C2=A0 Update Messages for Layer 3 address changes SHOULD cease when a ser= ver
=C2=A0 implementation determines that a client does NOT support Layer 3 =C2=A0 address tracking.

=C2=A0 If metric Sub-TLVs are supplied with the Peer Update message (e.g.<= br> =C2=A0 Maximum Data Rate), these metrics MUST be applied to all neighbor =C2=A0 sessions accessible via the peer.

=C2=A0 The Peer Update Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Peer =C2=A0 =C2=A0 |TLV Flags=3D0x10 | Length =3D 11 + | Sub-= TLVs as =C2=A0 |
=C2=A0| Update =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0| (Value TDB) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 30]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLEP_MESSA= GE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1= (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 22 + optio= nal Sub-TLVs

=C2=A0 Message Sequence Number =C2=A0- A 16-bit unsigned integer containin= g a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence number (generated by originator).
=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = TLV Length: =C2=A014 + length of optional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s= ub-TLVs.
=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 Address (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 Address (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Maximum Data Rate (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Current Data Rate (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Latency (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expected Forwarding Time (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resources (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Relative Link Quality (OPTIONAL)

15. Peer Update ACK Message

=C2=A0 A peer sends the Peer Update ACK Message to indicate whether a
=C2=A0 Peer Update Message was successfully processed.

=C2=A0 The Peer Update ACK message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Peer =C2=A0 =C2=A0 |TLV Flags=3D0x10 | Length =3D 11 + | Sub-= TLVs as =C2=A0 |
=C2=A0| Update ACK =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0| (Value TDB) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLEP_MESSA= GE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1= (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 - 0x0

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 31]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 22 + size = of optional sub-TLVs.

=C2=A0 Message Sequence Number =C2=A0- A 16-bit unsigned integer field con= taining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the sequence number from the Neighbor Up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message that is being acknowledged.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = TLV Length: =C2=A014 + optional sub-TLVs

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status (OPTIONAL)

16. Peer Termination Message

=C2=A0 The Peer Termination Message is sent by either the client or the =C2=A0 server when a session needs to be terminated. Transmission of a
=C2=A0 Peer Termination ACK message is required to confirm the
=C2=A0 termination process. The sender of the Peer Termination message
=C2=A0 is free to define its heuristics in event of a timeout. The
=C2=A0 receiver of a Peer Termination Message MUST terminate all
=C2=A0 neighbor sessions and release associated resources. State
=C2=A0 machines are returned to the "discovery" state. No Neighb= or Down
=C2=A0 messages are sent.

=C2=A0 The Peer Termination Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Peer =C2=A0 =C2=A0 |TLV Flags=3D0x10 | Length =3D 11 + | Sub-= TLVs as =C2=A0 |
=C2=A0| Termination =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0| (Value TDB) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- DLEP_MESSAGE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Set to 0x1 (bit 3, mhasseqnum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bit is set). All other bits a= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unused and MUST be set to = 9;0'.

=C2=A0 Message Address Length =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- 22 + size of optional sub-TLVs.

=C2=A0 Message Sequence Number =C2=A0 =C2=A0 =C2=A0 - A 16-bit unsigned in= teger field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 containing a sequence number<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 generated by the message orig= inator.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 32]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - TLV Length =3D 14 + optional sub-TLVs

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification (MANDATORY) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status (OPTIONAL)

17. Peer Termination ACK Message

=C2=A0 The Peer Termination Message ACK is sent by a DLEP peer in response=
=C2=A0 to a received Peer Termination order.

=C2=A0 The Peer Termination ACK Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A022 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D14 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Peer Term|TLV Flags=3D0x10 | Length =3D 11 + | Sub-TLVs as = =C2=A0 |
=C2=A0| ACK =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0| (Value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- DLEP_MESSAGE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Set to 0x1 (bit 3, mhasseqnum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bit is set). All other bits a= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unused and MUST be set to = 9;0'.

=C2=A0 Message Address Length =C2=A0 =C2=A0 =C2=A0 =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0- 22 + optional sub-TLVs.

=C2=A0 Message Sequence Number =C2=A0 =C2=A0 =C2=A0 - A 16-bit unsigned in= teger field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 containing the sequence numbe= r in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the corresponding Peer Termin= ation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Message being acknowledged.
=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - TLV Length =3D 14 + optional Sub-TLVs

=C2=A0 Sub-TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification (MANDATORY) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Status (OPTIONAL)

18. Neighbor Up Message

=C2=A0 A peer sends the Neighbor Up message to report that a new
=C2=A0 potential routing neighbor, or a new destination within the
=C2=A0 network, has been detected. A Neighbor Up ACK Message is required
=C2=A0 to confirm a received Neighbor Up. A Neighbor Up message can be
=C2=A0 sent by a client to signal that it (the client) has detected a new<= br>

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 33]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 neighbor, or by the server to indicate that new destinations
=C2=A0 (e.g. Multicast groups) exist within the network.

=C2=A0 The sender of the Neighbor Up Message is free to define its
=C2=A0 retry heuristics in event of a timeout. When a Neighbor Up
=C2=A0 message is received and successfully parsed, the receiver
=C2=A0 should enter an "in session" state with regard to the far= -end
=C2=A0 destination, and send an acknowledgement to the originating peer.
=C2=A0 The Neighbor Up Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A031 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D23 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Neighbor |TLV Flags=3D0x10 | Length =3D20 + =C2=A0| Sub-TLVs = as =C2=A0 |
=C2=A0| Up (TBD) =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLEP_MESSA= GE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1= (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 31 + optio= nal Sub-TLVs

=C2=A0 Message Sequence Number =C2=A0- A 16-bit unsigned integer field con= taining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a sequence number generated by the message =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0originator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = TLV Length: =C2=A023 + optional Sub-TLVs.

=C2=A0 Sub-TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 Address (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 Address (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Maximum Data Rate (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Current Data Rate (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Latency (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expected Forwarding Time (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resources (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Relative Link Factor (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Credit Window Status (OPTIONAL)

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 34]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

19. Neighbor Up ACK Message

=C2=A0 A peer sends the Neighbor Up ACK Message to indicate whether a
=C2=A0 Neighbor Up Message was successfully processed. When a peer
=C2=A0 receives a Neighbor Up ACK message containing a Status Sub-TLV
=C2=A0 with a status code of 0, the receiving peer should enter an "i= n
=C2=A0 session" state with respect to the far-end destination.

=C2=A0 The Neighbor Up ACK message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A035 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D 27 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Neighbor |TLV Flags=3D0x10 | Length =3D 24 =C2=A0 | Sub-TLVs = as =C2=A0 |
=C2=A0| Up ACK (TBD) =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | noted below =C2=A0= |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLEP_MESSA= GE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1= (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 35

=C2=A0 Message Sequence Number =C2=A0- A 16-bit unsigned integer field con= taining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the sequence number from the Neighbor Down =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message that is being acknowledged.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = TLV Length: =C2=A027

=C2=A0 Sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - = Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Credit Window Status (OPTIONAL)

20. Neighbor Down Message

=C2=A0 A DLEP peer sends the Neighbor Down message to report when a
=C2=A0 destination (a routing peer or a multicast group) is no longer
=C2=A0 reachable. The Neighbor Down message MUST contain a MAC Address TLV= .
=C2=A0 Any other TLVs present MAY be ignored. A Neighbor Down ACK Message = is
=C2=A0 required to confirm the process. The sender of the Neighbor Down =C2=A0 message is free to define its retry heuristics in event of a timeou= t.
=C2=A0 Upon successful receipt and parsing of a Neighbor Down message, the=

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 35]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 receiving peer MUST remove all state information for the destinatio= n,
=C2=A0 and send a Neighbor Down ACK message to the originating peer.

=C2=A0 The Neighbor Down Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 31 + optional =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLV =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0| =C2=A0TLVs Length =3D 23 + optional =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Sub-TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| TLV Type =3D =C2=A0 =C2=A0|TLV Flags=3D0x10 | Length =3D 20 + | Su= b-TLVs as =C2=A0 |
=C2=A0| DLEP Neighbor | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= optional Sub- | noted below =C2=A0 |
=C2=A0| Down (TBD) =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLE= P_MESSAGE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set= to 0x1 (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused an= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 31 = + optional TLVs

=C2=A0 Message Sequence Number =C2=A0 =C2=A0- A 16-bit unsigned integer fi= eld
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing a sequence number generate= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the message originator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0- TLV Length: 23 + optional Sub-TLVs

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status (OPTIONAL)

21. Neighbor Down ACK Message

=C2=A0 A peer sends the Neighbor Down ACK Message to indicate whether
=C2=A0 a received Neighbor Down Message was successfully processed. If
=C2=A0 successfully processed, the sending peer MUST remove all state
=C2=A0 information on the referenced neighbor session.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 36]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 The Neighbor Down ACK message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A035 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D 27 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Neighbor |TLV Flags=3D0x10 | Length =3D 24 =C2=A0 | Sub-TLVs = as =C2=A0 |
=C2=A0| Down ACK (TBD)| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | noted below =C2=A0 | =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLEP_MESSA= GE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1= (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 35

=C2=A0 Message Sequence Number =C2=A0- A 16-bit unsigned integer field con= taining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the sequence number from the Neighbor Down =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message that is being acknowledged.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = TLV Length: =C2=A027

=C2=A0 Sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - = Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status (MANDATORY)

22. Neighbor Update Message

=C2=A0 The client sends the Neighbor Update message when a change in link<= br> =C2=A0 metric parameters is detected for a destination.

=C2=A0 The Neighbor Update Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 31 + optional =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLV =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0| =C2=A0TLVs Length =3D 23 + optional =C2=A0|
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0|TLV Type =3D =C2=A0 =C2=A0 |TLV Flags=3D0x10 |Length =3D 20 + =C2= =A0|Sub-TLVs as =C2=A0 =C2=A0|
=C2=A0|DLEP Neighbor =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |optional Sub- =C2=A0|noted below =C2=A0 =C2=A0|
=C2=A0|Update (TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |TLVs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 37]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - DLEP_MESSAGE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- Set to 0x1 (bit 3, mhasseqnum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit is set). =C2=A0All other b= its are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unused and MUST be set to '= ;0'.

=C2=A0 Message Address Length =C2=A0 =C2=A0 =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - 31 + optional TLVs

=C2=A0 Message Sequence Number =C2=A0 =C2=A0 =C2=A0- A 16-bit unsigned int= eger field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing a sequence number,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generated by the message origi= nator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0- TLVs Length - 23 + optional Sub-TLVs.

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Maximum Data Rate (OPTIONAL) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Current Data Rate (OPTIONAL) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Latency (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resources (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Relative Link Quality (OPTIONA= L)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Credit Window Status (OPTIONAL= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Credit Grant (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Credit Request (OPTIONAL)

23. Neighbor Address Update Message

=C2=A0 The client sends the Neighbor Address Update message when a change<= br> =C2=A0 in Layer 3 addressing is detected for a neighbor session.

=C2=A0 The Neighbor Address Update Message contains the following fields:<= br>
=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A031 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D23 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Neighbor |TLV Flags=3D0x10 | Length =3D20 + =C2=A0| Sub-TLVs = as =C2=A0 |
=C2=A0| Address Update| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0|(TBD) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - DLEP_MESSAGE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- Set to 0x1 (bit 3, mhasseqnum bit is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set). =C2=A0All other bits are= unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 38]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Message Address Length =C2=A0 =C2=A0 =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 - 31 + optional TLVs

=C2=A0 Message Sequence Number =C2=A0 =C2=A0 =C2=A0- A 16-bit unsigned int= eger field
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing a sequence number,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generated by the message origi= nator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0- TLVs Length - 23 + optional Sub-TLVs.
=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification Sub-TLV (MANDAT= ORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address Sub-TLV (MANDATORY= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4 Address Sub-TLV (OPTIONAL= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 Address Sub-TLV (OPTIONAL= )

24. Neighbor Address Update ACK Message

=C2=A0 The server sends the Neighbor Address Update ACK Message to
=C2=A0 indicate whether a Neighbor Address Update Message was
=C2=A0 successfully processed.

=C2=A0 The Neighbor Address Update ACK message contains the following
=C2=A0 fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A035 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D 27 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Neighbor |TLV Flags=3D0x10 | Length =3D 24 =C2=A0 | Sub-TLVs = as =C2=A0 |
=C2=A0| Address Update| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | noted below =C2=A0 | =C2=A0| ACK (TBD) =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - DLEP_MESSA= GE (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Set to 0x1= (bit 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is set). All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0 - 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - 35

=C2=A0 Message Sequence Number =C2=A0- A 16-bit unsigned integer field con= taining
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the sequence number from the Neighbor Down =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message that is being acknowledged.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = TLV Length: =C2=A027

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 39]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identification Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC Address Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status Sub-TLV (MANDATORY)

25. Heartbeat Message

=C2=A0 A Heartbeat Message is sent by a peer every N seconds, where N is =C2=A0 defined in the "Heartbeat Interval" field of the discover= y message.
=C2=A0 The message is used by peers to detect when a DLEP session partner<= br> =C2=A0 is no longer communicating. Peers SHOULD allow some integral number=
=C2=A0 of heartbeat intervals (default 4) to expire with no traffic on the=
=C2=A0 session before initiating DLEP session termination procedures.

=C2=A0 The Heartbeat Message contains the following fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Heartbeat|TLV Flags=3D0x10 | Length =3D 11 =C2=A0 | Sub-TLVs = as =C2=A0 |
=C2=A0| (TBD) =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | n= oted below =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DLEP_MESSAG= E (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Set to 0x1 (bit = 3, mhasseqnum bit is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 set). All other bits are unused and SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 be set to '0'.

=C2=A0 Message Address Length =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 22

=C2=A0 Message Sequence Number - A 16-bit unsigned integer field containin= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 a sequence number generated by the message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 originator.

=C2=A0 TLV Block - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLV Le= ngth =3D 14

=C2=A0 Sub TLVs =C2=A0-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Identification Sub-TLV (MANDATORY)

26. Link Characteristics Request Message

=C2=A0 The Link Characteristics Request Message is sent by the server to =C2=A0 the client when the server detects that a different set of
=C2=A0 transmission characteristics is necessary (or desired) for the

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 40]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 type of traffic that is flowing on the link. It is important to
=C2=A0 note that the link can be a logical link for a multicast session =C2=A0 where more than one remote neighbor participates. The request
=C2=A0 contains either a Current Data Rate (CDR) TLV to request a differen= t
=C2=A0 amount of bandwidth than what is currently allocated, a Latency
=C2=A0 TLV to request that traffic delay on the link not exceed the
=C2=A0 specified value, or both. A Link Characteristics ACK Message is
=C2=A0 required to complete the request. Implementations are free to
=C2=A0 define their retry heuristics in event of a timeout. Issuing a
=C2=A0 Link Characteristics Request with ONLY the MAC Address TLV is a
=C2=A0 mechanism a peer MAY use to request metrics (via the Link
=C2=A0 Characteristics ACK) from its partner.

=C2=A0 The Link Characteristics Request Message contains the following
=C2=A0 fields:

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A031 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D23 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Link Char|TLV Flags=3D0x10 | Length =3D20 + =C2=A0| Sub-TLVs = as =C2=A0 |
=C2=A0| Request (TBD) | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DLEP_MESSAG= E (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Set to 0x1 (bit = 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 is set). =C2=A0All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 31 + length= of optional (Current Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Rate and/or Latency) Sub-TLVs

=C2=A0 Message Sequence Number - A 16-bit unsigned integer field containin= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 a sequence number generated by the message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 originator.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Length= : 23 + optional Sub-TLVs

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Identification Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 MAC Address Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Current Data Rate Sub-TLV - if present,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 this value represents the requested data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 rate in bits per second (bps). (OPTIONAL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Latency TLV - if present, this value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 represents the maximum latency, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 milliseconds, desired on the link.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (OPTIONAL)
Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 41]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

27. Link Characteristics ACK Message

=C2=A0 The Link Characteristics ACK Message is sent by the client to the =C2=A0 server letting the server know the success (or failure) of the
=C2=A0 requested change in link characteristics. =C2=A0The Link Characteri= stics
=C2=A0 ACK message SHOULD contain a complete set of metric TLVs. It MUST =C2=A0 contain the same TLV types as the request. The values in the
=C2=A0 metric TLVs in the Link Characteristics ACK message MUST reflect =C2=A0 the link characteristics after the request has been processed.

=C2=A0 The Link Characteristics ACK Message contains the following fields:=

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 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
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0Msg Type =3D =C2=A0 |Msg Flg|AddrLen| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| DLEP_MESSAGE =C2=A0| 0x1 =C2=A0 | 0x0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A031 + size of opt =C2=A0 =C2=A0 =C2=A0 |
=C2=A0| (value TBD) =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sub-TLVs =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message Seq Num =C2=A0 =C2=A0 = =C2=A0|TLVs Length =3D23 + opt sub-TLVs |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+
=C2=A0| DLEP Link Char|TLV Flags=3D0x10 | Length =3D20 + =C2=A0| Sub-TLVs = as =C2=A0 |
=C2=A0| ACK (TBD) =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | opt sub-TLVs =C2=A0| noted below =C2=A0 |
=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<= u>+-+-+

=C2=A0 Message Type =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DLEP_MESSAG= E (Value TBD)

=C2=A0 Message Flags =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Set to 0x1 (bit = 3, mhasseqnum bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 is set). =C2=A0All other bits are unused and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 MUST be set to '0'.

=C2=A0 Message Address Length =C2=A0- 0x0

=C2=A0 Message Size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- 31 + length= of optional (Current Data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Rate and/or Latency) TLVs

=C2=A0 Message Sequence Number - A 16-bit unsigned integer field containin= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 the sequence number that appeared on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 corresponding Link Characteristics Request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 message.

=C2=A0 TLV Block =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - TLVs L= ength =3D 23 + Optional TLVs

=C2=A0 Sub TLVs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Identification Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 MAC Address Sub-TLV (MANDATORY)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Maximum Data Rate Sub-TLV (OPTIONAL)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Current Data Rate Sub-TLV - if present,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 this value represents the NEW (or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 unchanged, if the request is denied)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Current Data Rate in bits per second (bps).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (OPTIONAL)

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 42]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Latency Sub-TLV - if present, this value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 represents the NEW maximum latency (or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 unchanged, if the request is denied),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 expressed in milliseconds, on the link.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (OPTIONAL)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Resources Sub-TLV (OPTIONAL)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Relative Link Quality Sub-TLV (OPTIONAL)

28. =C2=A0Security Considerations

=C2=A0 The protocol does not contain any mechanisms for security (e.g.
=C2=A0 authentication or encryption). The protocol assumes that any
=C2=A0 security would be implemented in the underlying transport (for
=C2=A0 example, by use of DTLS or some other mechanism), and is
=C2=A0 therefore outside the scope of this document.

UH> I think there may be some more requirements for this section, in
particular an allignment with RFC5444. I think this is nicely done in
RFC6130. This document should also specify how messages may be
rejected as invalid by a security extension.

29. =C2=A0IANA Considerations

=C2=A0 This section specifies requests to IANA.

UH> It could be helpful for IANA to provide tables with initial
assignments of the values, such as in RFC6130.

29.1 =C2=A0TLV Registrations

=C2=A0 This specification defines:

=C2=A0 o =C2=A0One TLV types which must be allocated from the 0-223 range<= br> =C2=A0 =C2=A0 =C2=A0of the "Assigned Message TLV Types" reposito= ry of [RFC5444].

=C2=A0 o =C2=A0A new repository for DLEP orders, with seventeen values cur= rently
=C2=A0 =C2=A0 =C2=A0assigned.

=C2=A0 o =C2=A0A new repository for DLEP Sub-TLV assignments with nineteen= values
=C2=A0 =C2=A0 =C2=A0currently assigned.

29.2 =C2=A0Expert Review: Evaluation Guidelines

=C2=A0 For the registries for TLV type extensions where an Expert Review i= s
=C2=A0 required, the designated expert SHOULD take the same general
=C2=A0 recommendations into consideration as are specified by [RFC5444].

29.3 =C2=A0Message TLV Type Registration

=C2=A0 The Message TLV specified below must be allocated from the "Me= ssage
=C2=A0 TLV Types" namespace of [RFC5444].

=C2=A0 =C2=A0 =C2=A0 o =C2=A0 DLEP_MESSAGE

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 43]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

29.4 =C2=A0DLEP Order Registration

=C2=A0 A new repository must be created with the values of the DLEP orders= .
=C2=A0 Valid orders are:

=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Attached Peer Discovery Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Detached Peer Discovery Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Peer Offer Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Peer Update Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Peer Update ACK Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Peer Termination Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Peer Termination ACK Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Up Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Up ACK Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Down Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Down ACK Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Update Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Address Update Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Neighbor Address Update ACK Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Heartbeat Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Link Characteristics Request Message
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Link Characteristics ACK Message

=C2=A0 This registry should be created according to the guidelines for
=C2=A0 'Message-Type-Specific TLV' registration as specified in se= ction
=C2=A0 6.2.1 of [RFC5444].

29.5 =C2=A0DLEP Sub-TLV Type Registrations

=C2=A0 A new repository for DLEP Sub-TLVs must be created. Valid Sub-TLVs = are:

=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Identification Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 DLEP Version Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Peer Type Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 MAC Address Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 IPv4 Address Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 IPv6 Address Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Maximum Data Rate Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Current Data Rate Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Latency Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Expected Forwarding Time Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Resources Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Relative Link Quality Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Status Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Heartbeat Interval Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Heartbeat Threshold Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Link Characteristics ACK Timer Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Credit Window Status Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Credit Grant Sub-TLV
=C2=A0 =C2=A0 =C2=A0 o =C2=A0 Credit Request Sub-TLV

=C2=A0 It is also requested that the registry allocation contain space
=C2=A0 reserved for experimental sub-TLVs.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 44]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

30. Appendix A.

Peer Level Message Flows

UH> I think the whole message flow should be described in much more
detail in the main document, such as in RFC6130. How are messages
processed/generated, in which order, what happens if messages are not
received, which timers are used etc.

*Modem Device (Client) Restarts Discovery

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 <-------Peer Discovery--------- =C2=A0 =C2=A0Client initiates di= scovery

=C2=A0 =C2=A0---------Peer Offer-----------> =C2=A0 Server detects a pr= oblem, sends
=C2=A0 =C2=A0 =C2=A0w/ Non-zero Status TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Peer Offer w/ Status TLV indicating
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the error.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client accepts f= ailure, restarts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discovery proces= s.

=C2=A0 <-------Peer Discovery--------- =C2=A0 =C2=A0Client initiates di= scovery

=C2=A0 =C2=A0---------Peer Offer-----------> =C2=A0 Server accepts, sen= ds Peer Offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 w/ Zero Status TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 w/ Status TLV indicating success.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discovery comple= ted.

*Modem Device Detects Peer Offer Timeout

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 <-------Peer Discovery--------- =C2=A0 =C2=A0Client initiates di= scovery,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0starts a guard t= imer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client guard tim= er expires.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client restarts = discovery process.

=C2=A0 =C2=A0<-------Peer Discovery--------- =C2=A0 Client initiates di= scovery,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0starts a guard t= imer.

=C2=A0 =C2=A0---------Peer Offer-----------> =C2=A0 Server accepts, sen= ds Peer Offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 w/ Zero Status TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 w/ Status TLV indicating success.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discovery comple= ted.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 45]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

*Server Peer Offer Lost

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 <-------Peer Discovery--------- =C2=A0 =C2=A0Client initiates di= scovery,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0starts a guard t= imer.

=C2=A0 =C2=A0---------Peer Offer-------|| =C2=A0 =C2=A0 =C2=A0Server offer= s availability

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client times out= on Peer Offer,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0restarts discove= ry process.

=C2=A0 <-------Peer Discovery--------- =C2=A0 =C2=A0Client initiates di= scovery

=C2=A0 =C2=A0---------Peer Offer-----------> =C2=A0 Server detects subs= equent discovery,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0internally termi= nates the previous,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accepts the new = association, sends
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Peer Offer w/ St= atus TLV indicating
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0success.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Discovery comple= ted.

*Discovery Success

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 <-------Peer Discovery--------- =C2=A0 =C2=A0Client initiates di= scovery

=C2=A0 =C2=A0---------Peer Offer-----------> =C2=A0 Server offers avail= ability

=C2=A0 =C2=A0-------Peer Heartbeat--------->

=C2=A0 <-------Peer Heartbeat---------

=C2=A0 =C2=A0-------Peer Heartbeat--------->

=C2=A0 <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D> =C2=A0 Neighbor Sessions

=C2=A0 <-------Peer Heartbeat---------

=C2=A0 =C2=A0-------Peer Heartbeat--------->

=C2=A0 =C2=A0--------Peer Term Req---------> =C2=A0 Terminate Request
=C2=A0 <--------Peer Term Res--------- =C2=A0 =C2=A0Terminate Response<= br>

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 46]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

*Server Detects a Heartbeat timeout

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 <-------Peer Heartbeat---------

=C2=A0 =C2=A0-------Peer Heartbeat--------->

=C2=A0 =C2=A0 =C2=A0||---Peer Heartbeat---------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD= =EF=BF=BD =EF=BF=BD =EF=BF=BD

=C2=A0 =C2=A0-------Peer Heartbeat--------->

=C2=A0 =C2=A0 =C2=A0||---Peer Heartbeat---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server Heartbeat= Timer expires,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0detects missing = heartbeats. Server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0takes down all n= eighbor sessions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and terminates t= he Peer association.

=C2=A0 =C2=A0------Peer Terminate ---------> =C2=A0 Peer Terminate Requ= est

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client takes dow= n all neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sessions, then a= cknowledges the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Peer Terminate
=C2=A0 <----Peer Terminate ACK--------- =C2=A0 Peer Terminate ACK

*Client Detects a Heartbeat timeout

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 <-------Peer Heartbeat---------

=C2=A0 =C2=A0-------Peer Heartbeat------||

=C2=A0 <-------Peer Heartbeat---------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD= =EF=BF=BD =EF=BF=BD =EF=BF=BD

=C2=A0 =C2=A0-------Peer Heartbeat------||

=C2=A0 <-------Peer Heartbeat---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client Heartbeat= Timer expires,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0detects missing = heartbeats. Modem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0takes down all n= eighbor sessions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and terminates t= he Peer association.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 47]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

=C2=A0 =C2=A0<-------Peer Terminate-------- =C2=A0 =C2=A0Peer Terminate= Request

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server takes dow= n all neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sessions, then a= cknowledges the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Peer Terminate
=C2=A0 =C2=A0------Peer Terminate ACK-----> =C2=A0 =C2=A0Peer Terminate= ACK

*Peer Terminate (from Client) Lost

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0 ||------Peer Terminate-------- =C2=A0 Client Peer Terminate = Request

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server Heartbeat= times out,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0terminates assoc= iation.

=C2=A0 =C2=A0--------Peer Terminate-------> =C2=A0 =C2=A0Server Peer Te= rminate

=C2=A0 =C2=A0<-----Peer Terminate ACK------ =C2=A0 =C2=A0Client sends P= eer Terminate ACK

*Peer Terminate (from server) Lost

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0-------Peer Terminate--------> =C2=A0 =C2=A0Server Peer Te= rminate Request

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client HB times = out,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0terminates assoc= iation.

=C2=A0 =C2=A0<------Peer Terminate-------- =C2=A0 =C2=A0 Client Peer Te= rminate

=C2=A0 =C2=A0------Peer Terminate ACK-----> =C2=A0 =C2=A0Peer Terminate= ACK

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 48]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

Neighbor Level Message Flows

*Client Neighbor Up Lost

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0||-----Neighbor Up ------------ =C2=A0 Client sends Neighbor = Up

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client timesout = on ACK

=C2=A0 =C2=A0<------Neighbor Up ------------ =C2=A0 Client sends Neighb= or Up

=C2=A0 =C2=A0------Neighbor Up ACK---------> =C2=A0 Server accepts the = neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session

=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. . . . . . . .
=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics

*Server Detects Duplicate Neighbor Ups

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0<------Neighbor Up ------------ =C2=A0 Client sends Neighb= or Up

=C2=A0 =C2=A0------Neighbor Up ACK-------|| =C2=A0 =C2=A0Server accepts th= e neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client timesout = on ACK

=C2=A0 =C2=A0<------Neighbor Up ------------ =C2=A0 Client resends Neig= hbor Up

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server detects d= uplicate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Neighbor, takes = down the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0previous, accept= s the new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Neighbor.

=C2=A0 =C2=A0------Neighbor Up ACK---------> =C2=A0 Server accepts the = neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session

=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. . . . . . . .
=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 49]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

*Neighbor Up, No Layer 3 Addresses

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 =C2=A0Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0<------Neighbor Up ------------ =C2=A0 Client sends Neighb= or Up

=C2=A0 =C2=A0------Neighbor Up ACK---------> =C2=A0 Server accepts the = neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server ARPs for = IPv4 if defined.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server drives ND= for IPv6 if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0defined.

=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. . . . . . . .
=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics

*Neighbor Up with IPv4, No IPv6

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0<------Neighbor Up ------------ =C2=A0 Client sends Neighb= or Up with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the IPv4 TLV

=C2=A0 =C2=A0------Neighbor Up ACK---------> =C2=A0 Server accepts the = neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server drives ND= for IPv6 if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0defined.

=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. . . . . . . .
=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics

*Neighbor Up with IPv4 and IPv6

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0<------Neighbor Up ------------ =C2=A0 Client sends Neighb= or Up with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the IPv4 and IPv= 6 TLVs

=C2=A0 =C2=A0------Neighbor Up ACK---------> =C2=A0 Server accepts the = neighbor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session

=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. . . . . . . .
=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0Client Neighbor Met= rics

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 50]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

*Neighbor Session Success

=C2=A0 Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Client =C2=A0 Message Description
=C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

=C2=A0 =C2=A0---------Peer Offer-----------> =C2=A0 Server offers avail= ability

=C2=A0 =C2=A0-------Peer Heartbeat--------->

=C2=A0 <------Neighbor Up ----------- =C2=A0 =C2=A0 =C2=A0Client

=C2=A0 =C2=A0------Neighbor Up ACK--------> =C2=A0 =C2=A0 Server

=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0 Client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. . . . . . . .
=C2=A0 <------Neighbor Update--------- =C2=A0 =C2=A0 Client

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Client initiate= s the terminate

=C2=A0 <------Neighbor Down ---------- =C2=A0 =C2=A0 Client

=C2=A0 =C2=A0------Neighbor Down ACK-------> =C2=A0 =C2=A0Server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server initiate= s the terminate

=C2=A0 =C2=A0------Neighbor Down ----------> =C2=A0 =C2=A0Server

=C2=A0 <------Neighbor Down ACK------- =C2=A0 =C2=A0 Client

Acknowledgements

=C2=A0 The authors would like to acknowledge the influence and contributio= ns
=C2=A0 of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Ric= k
=C2=A0 Taylor, and John Dowdell.

UH> Of course you are free to list in any given order. I am just
wondering if an alphabetical order would not be more common.

Normative References

=C2=A0 [RFC5444] Clausen, T., Ed,. "Generalized Mobile Ad Hoc Network= (MANET)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet/Message Format", RFC= 5444, Februar, 2009.

=C2=A0 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics&= quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 5578, February 2010.

=C2=A0 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requirement Levels", RFC 21= 19, March 1997.

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 51]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0DLEP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 February 2012

Informative References

=C2=A0 [DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security&q= uot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 4347, April 2006.

UH> s/[DTLS]/[RFC4347]/

Author's Addresses

=C2=A0 Stan Ratliff
=C2=A0 Cisco
=C2=A0 170 West Tasman Drive
=C2=A0 San Jose, CA =C2=A095134
=C2=A0 USA
=C2=A0 EMail: srat= liff@cisco.com

=C2=A0 Bo Berry
=C2=A0 Cisco
=C2=A0 170 West Tasman Drive
=C2=A0 San Jose, CA =C2=A095134
=C2=A0 USA
=C2=A0 EMail: bober= ry@cisco.com

=C2=A0 Greg Harrison
=C2=A0 Cisco
=C2=A0 170 West Tasman Drive
=C2=A0 San Jose, CA =C2=A095134
=C2=A0 USA
=C2=A0 EMail: greh= arri@cisco.com

=C2=A0 Shawn Jury
=C2=A0 NetApp
=C2=A0 7301 Kit Creek Road, Building 2
=C2=A0 Research Triangle Park, NC 27709
=C2=A0 USA
=C2=A0 Email: s= hawn.jury@netapp.com

=C2=A0 Darryl Satterwhite
=C2=A0 Cisco
=C2=A0 170 West Tasman Drive
=C2=A0 San Jose, CA =C2=A095134
=C2=A0 USA
=C2=A0 Email: dsat= terw@cisco.com

Ratliff et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires August 6, 2= 012 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 52]
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b10cb110ac7d504bb4cc03e-- From valerio.arnaboldi@iit.cnr.it Fri Mar 16 03:12:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B4C21F86B4 for ; Fri, 16 Mar 2012 03:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.275 X-Spam-Level: * X-Spam-Status: No, score=1.275 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzsy1fp+YgyH for ; Fri, 16 Mar 2012 03:12:37 -0700 (PDT) Received: from irina.iit.cnr.it (irina-lan.iit.cnr.it [146.48.96.79]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E621F86AF for ; Fri, 16 Mar 2012 03:12:36 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id 65DCA3D8048; Fri, 16 Mar 2012 11:12:03 +0100 (CET) Date: Fri, 16 Mar 2012 11:12:03 +0100 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <4f6311f3.z8y1D+SP+nWNFnxx%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [manet] Computer Communications journal: Special Issue on Information-Centric Networking X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 10:12:38 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CALL FOR PAPERS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 Elsevier - Computer Communications Journal =09 Special Issue on Information-Centric Networking =09 *** Submission deadline: April. 15, 2012 *** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Information-Centric Networking (ICN) is proposed as an architecture for the future Internet. The basic idea is to make units of information accessible to the networking protocols and turn them into the unit of networking. Main advantages are conjectured to come from a much better support for mobility, data security, as well as caching and replication. ICN has by now been investigated in a number of projects. This special issue aims to collect new, innovative material on the theory, the design, and the practical applicability of ICN. In particular, material that advances the level of maturity, scalability and real-life dependability of ICN are welcome. Topics of interest include (but are not limited to) the following: - Analytic models for the behavior of information-centric networking, especially for scalability properties - Models for workloads (both amount of traffic as well as kinds and size of objects along with request patterns) - Capacity analysis of ICN - Caching in ICN, in particular, cache placement and cache management (e.g., replacement algorithms) along with resource management for caches, links, and routers - Coexistence of ICN protocol stacks with legacy stacks (e.g., IP) as well as coexistence of multiple ICNs with each other on the same network fabric - Suitability of ICN for all kinds of workloads, in particular, streaming and interactive multimedia workloads - Security in ICN - Mobility support by ICN - Energy efficiency of ICN - Active objects in ICN, adding functionality and execution semantics to information objects - Consistency and coherence models for replicated, static or active information objects, along with revision handling and updating protocols - Structuring applications on top of ICN (both legacy and possible new applications) as well as suitable application programming interfaces (complementing or replacing a "socket"-style interface standard) - Interoperability between different ICN solutions - Practical experience, test-beds, open-source software Tentative Schedule Submission deadline: April. 15, 2012 Author notification: June 30, 2012 Revised paper due: July 31, 2012 Final author notification: September 1, 2012 Guest Editors Bengt Ahlgren, Swedish Insitute of Computer Science Holger Karl, Universitat Paderborn Dirk Kutscher, NEC Laboratories, Europe Lixia Zhang, UCLA Instructions for submission: The submission website for this journal is located at http://ees.elsevier.com/comcom. To ensure that all manuscripts are correctly identified for consideration by the Special Issue, the authors should select "Special Issue: Information-Centric Networking" when they reach the "Article Type" step in the submission process.= From Chris.Dearlove@baesystems.com Fri Mar 16 04:43:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D933521F8555 for ; Fri, 16 Mar 2012 04:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvEDsZWPJFxV for ; Fri, 16 Mar 2012 04:43:00 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8048021F854D for ; Fri, 16 Mar 2012 04:42:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208";a="195300930" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Mar 2012 11:42:58 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2GBgvTi015433; Fri, 16 Mar 2012 11:42:58 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 11:42:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 11:42:56 -0000 Message-ID: In-Reply-To: <0EAC6016-E342-4DFE-87C6-A6E0DCD141AB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] First feedback on DLEP draft 2 Thread-Index: Ac0CzHt8jvcMutYJRUiA8/oFPNI0bQAm+ZIQ References: <4F61BBAB.6070600@fkie.fraunhofer.de> <0EAC6016-E342-4DFE-87C6-A6E0DCD141AB@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 16 Mar 2012 11:42:57.0729 (UTC) FILETIME=[EED97310:01CD0369] Cc: manet@ietf.org Subject: Re: [manet] First feedback on DLEP draft 2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 11:43:01 -0000 Not having looked at the details recently, can you use the type extension f= ield to use multiple type extensions from a single TLV type? There is also = a message type specific set of TLVs, but there are drawbacks in their use, = so I'm not suggesting them. As I recall, what I was not entirely happy (again, I haven't checked the la= test draft) with was the way addresses had to be packed into TLVs, rather t= han address blocks. That of course is due to a limitation of 5444 in that a= rea. In defence of 5444 we had to make tradeoffs of simplicity, flexibility= and extensibility, with pressures in all three directions. It would be pos= sible to extend 5444 to add a new address block flag so that an address blo= ck could override the previously set address length. But that also has draw= backs, not least in leaving existing protocols that use 5444 unspecified as= to how they would relate to such a hypothetical 5444bis. For that reason I= 'm not suggesting this. But if we'd had perfect foresight we might (there a= re arguments the other way too) have done this differently. --=20 Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: 15 March 2012 16:55 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] First feedback on DLEP draft 2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Henning, Glad to hear that you are developing an implementation! The sub-TLV's were created based on earlier comments. The concern =20 expressed at the time was that DLEP was going to consume an inordinate =20 amount of the TLV space reserved in RFC5444. So in that respect, it =20 feels like we're somewhat "between a rock and a hard place"... ;-) Regards, Stan On Mar 15, 2012, at 5:51 AM, Henning Rogge wrote: > Hello, > > I am working on a DLEP prototype implementation at the moment, so I =20 > had to take a closer look to the current draft. While getting the =20 > necessary infrastructure in place to work with DLEP, I noticed one =20 > thing I would like to raise here on the list. > > Is there a reason why DLEP invents its own variant of RFC5444 (the =20 > sub-tlvs)? > > I cannot see why this is necessary. Instead of placing TLVs into the =20 > binary value of another TLV, we could just add them as message-TLVs =20 > too. This would allow DLEP to be read and generated by standard RFC =20 > 5444 code. Each message would contain a single order (encoded with a =20 > mandatory 'order' message-TLV) and a series of additional message-=20 > TLVs which contain the parameters of the order. > > Each order would be put into a message of its own, which still can =20 > be bundled into a single packet to keep orders attached as a 'block'. > > I think this could simplify the DLEP draft quite a bit, because it =20 > make description of the binary structure unnecessary (its already =20 > described in RFC 5444) and would make it easier to mix DLEP messages =20 > with other protocols into the same RFC 5444 datastream if necessary. > > I am still working through the existing metric TLVs of DLEP at the =20 > moment and look for other metric values that would be useful for =20 > DLEP, I will write another mail as soon as I have finished a full =20 > review of the draft. > > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Mar 16 04:45:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F021F865D for ; Fri, 16 Mar 2012 04:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRe9Y9ljKvkK for ; Fri, 16 Mar 2012 04:45:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id CFBA321F8562 for ; Fri, 16 Mar 2012 04:45:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208";a="195301987" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Mar 2012 11:45:28 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2GBjRFE017356; Fri, 16 Mar 2012 11:45:27 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 11:45:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 16 Mar 2012 11:45:26 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] First feedback on DLEP draft 2 Thread-Index: Ac0C2SktRV4Y4nrxQMix54/2gF0t3gAkOwBQ References: <4F61BBAB.6070600@fkie.fraunhofer.de><0EAC6016-E342-4DFE-87C6-A6E0DCD141AB@cisco.com>

From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , "Stan Ratliff" X-OriginalArrivalTime: 16 Mar 2012 11:45:27.0748 (UTC) FILETIME=[48448840:01CD036A] Cc: manet@ietf.org Subject: Re: [manet] First feedback on DLEP draft 2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 11:45:31 -0000 Not quite, Some message and address block TLVs are message type specific, some are global. Note that all those defined so far (e.g. for NHDP) are global. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 15 March 2012 18:26 To: Stan Ratliff Cc: manet@ietf.org Subject: Re: [manet] First feedback on DLEP draft 2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- RFC5444 has (according to my knowledge) three kinds of TLVs. a) Packet TLVs b) Message TLVs c) Address TLVs b) and c) are message ID specific. so if DLEP has its own message type, it will contain its own registry for Message and Address TLVs. The HELLO message of NHDP has its own Message-TLV Registry... as will the TC message of OLSRv2. Henning Rogge On Thu, Mar 15, 2012 at 19:06, Stan Ratliff wrote: > > On Mar 15, 2012, at 1:05 PM, Henning Rogge wrote: > >> On Thu, Mar 15, 2012 at 17:55, Stan Ratliff wrote: >>> >>> Henning, >>> >>> Glad to hear that you are developing an implementation! >> >> I am working on an EU project (http://confine-project.eu) which (among >> other things) develops a virtualized container for doing research on >> mesh nodes. And we would like to use DLEP to get layer-2 data from the >> original WLAN cards into the container without giving them full >> control over the card. >> >>> The sub-TLV's were created based on earlier comments. The concern >>> expressed >>> at the time was that DLEP was going to consume an inordinate amount of >>> the >>> TLV space reserved in RFC5444. So in that respect, it feels like we're >>> somewhat "between a rock and a hard place"... ;-) >> >> Doesn't each RFC 5444 message have its own registry of Message-TLVs? >> >> My idea was to add a "Order" TLV for the DLEP message so DLEP only >> needs a single Message-Type. Inside this message type DLEP would have >> 256 TLVs of its own, each with 256 extension types. >> > > Uhhh, perhaps I'm showing my RFC 5444 ignorance here, but I'm not sure what > you mean. Can you explain? > > Regards, > Stan > > >> And maybe even Addresses and Address TLVs might be useful for DLEP. >> >> What do you think about me trying to implement DLEP with the existing >> datatypes in this way, so you can have a look at the result and see if >> the DLEP draft can be cleaned up this way? >> >> Henning Rogge >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Fri Mar 16 05:26:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615AC21F861E for ; Fri, 16 Mar 2012 05:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeH+DqW8OvEL for ; Fri, 16 Mar 2012 05:26:13 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8FC21F8604 for ; Fri, 16 Mar 2012 05:26:12 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S8WES-0002xZ-5Z; Fri, 16 Mar 2012 13:26:08 +0100 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1S8WES-0002Hx-2u; Fri, 16 Mar 2012 13:26:08 +0100 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 13:26:08 +0100 Message-ID: <4F633154.4070404@fkie.fraunhofer.de> Date: Fri, 16 Mar 2012 13:25:56 +0100 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <4F61BBAB.6070600@fkie.fraunhofer.de> <0EAC6016-E342-4DFE-87C6-A6E0DCD141AB@cisco.com>

<49601379-4688-4BA6-BB4C-E57385B5BF9D@cisco.com> <5426CEA6-63FA-43BD-A24E-009EB9E2A563@cisco.com> In-Reply-To: <5426CEA6-63FA-43BD-A24E-009EB9E2A563@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070803000000020804090905" X-OriginalArrivalTime: 16 Mar 2012 12:26:08.0234 (UTC) FILETIME=[F6E924A0:01CD036F] X-Virus-Scanned: yes (ClamAV 0.97.3/14654/Fri Mar 16 00:06:42 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 47038d4608512714aed85b3039ae6c65 Cc: Christoph Barz , sratliff@cisco.com Subject: Re: [manet] First feedback on DLEP draft 2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:26:17 -0000 This is a cryptographically signed message in MIME format. --------------ms070803000000020804090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I will try to describe my concept of using DLEP without sub-TLVs. The=20 mail became a little bit longer than I planned, but I wanted to explain=20 the idea detailed enough. First a few ideas I used in the following text: - I would suggest using other words than server/client for the DLEP=20 peers, because they are not intuitive to understand. My suggestion would = be using DLEP-Interface for the former client and DLEP-Router for the=20 former server. This will describe the default use case quite nicely. - I am not sure how the Detached Peer Discovery should work, because=20 DLEP does not specify communication between multiple DLEP-Interfaces. - I skipped the Credit Grant scheme in this writeup, because I am not=20 sure about its details. - I also put together all ACK messages into a single Order type, which=20 simplifies the protocol description. - I think there are more options for simplification, but we can discuss=20 them later. DLEP Messages =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Each DLEP command/order is contained in a single RFC 5444 message with=20 the message type "DLEP". Each of this messages MUST contain a message=20 sequence number as specified in RFC 5444, Chapter 5.2. Message sequence=20 numbers MUST be increased by each message of a peer and use the range of = 0-65535. The address length of a DLEP message SHOULD be set to 16, to allow MAC,=20 IPv4 and IPv6 addresses (and mixture of all three). If the DLEP peer=20 does not support IPv6, is CAN set the address length to 6. DLEP messages CAN contain one or more addresses of different types. Each = of these addresses MUST contain a "Address Type" TLV, which describes=20 the number of used bytes of the RFC 5444 address, beginning with the=20 first byte. The rest of the address MUST be padded with zero bytes,=20 which can be compressed with the ahaszerotail option of the address=20 block (see RFC 5444, Section 5.3). All custom DLEP message and address TLVs MUST be allocated from the=20 Message-Type specific id range as defined in RFC 5444, chapter 6.1. Each DLEP message MUST contain a "DLEP-Order" message-TLV, which=20 extension type specifies the order the message. Each DLEP message CAN contain an "Identification" message-TLV, if the=20 underlaying transport mechanism does not allow DLEP to distinguish=20 between endpoints of the router-interface communication. Each DLEP message CAN contain a "Peer Type" message-TLV, which describes = the peer of the DLEP communication with a human readable identification=20 string. If a DLEP message is a response to a former message of its peer, it MUST = contain a "Reference" message-TLV, which describes the order of the=20 referred message and its message sequence number. DLEP Order: Peer Discovery =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D The Peer Discovery is sent by the DLEP-Interface to announce its=20 existence to DLEP-Routers on its local interface. It CAN announce the interval and validity time of the heartbeat of the=20 Router. Message TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Version TLV (optional) - Peer Type TLV (optional) - Heartbeat Interval TLV (optional) - Heartbeat Validity Time TLV (optional) DLEP Order: Peer Offer =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Peer Offer is sent by the DLEP-Router to acknowledge the presence of = the DLEP-Interface and setup a session with the Interface. It CAN announce the interval and validity time of the heartbeat of the=20 Router. Message TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Version TLV (optional) - Peer Type TLV (optional) - Heartbeat Interval TLV (optional) - Heartbeat Validity Time TLV (optional) DLEP Order: Peer Termination =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D The Peer Update CAN be sent by both the DLEP-Router and the=20 DLEP-Interface to signal that it considers the session terminated. If the session was terminated because of a message by the peer, this=20 message should contain a Status TLV. Message TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Status TLV (optional) DLEP Order: Peer Update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Peer Update CAN be sent by both the DLEP-Router and the=20 DLEP-Interface to update some global data of the peer. The Peer Update message of the DLEP-Router CAN contain addresses with=20 address TLVs to reflect a local address change. The Peer Update message of the DLEP-Interface CAN contain metric TLVs to = reflect global changes of its connected network link. Message TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Current Data Rate TLV (optional for DLEP-Interface) - Maximum Data Rate TLV (optional for DLEP-Interface) - Latency TLV (optional for DLEP-Interface) - Expected Forwarding Time TLV (optional for DLEP-Interface) - Resources TLV (optional for DLEP-Interface) - Relative Link Quality TLV (optional for DLEP-Interface) DLEP Order: Link Characteristics Request =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Link Characteristics Request is sent by the DLEP-Router to request a = change in the Peers interface. It CAN contain a single Address with the Address Type "MAC" to request a = change of the network mac address of the peer. Message TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Current Data Rate TLV (optional for DLEP-Interface) DLEP Order: Heartbeat =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Heartbeat CAN be sent by both the DLEP-Router and the DLEP-Interface.= Message-TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - INTERVAL TIME TLV (optional, see RFC 5497, Section 9.2) - VALIDITY_TIME TLV (optional, see RFC 5497, Section 9.2) DLEP Order: Neighbor Up =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Neighbor Up is sent by the DLEP-Interface when a new neighbor is=20 detected on the network. It CAN contain multiple addresses which reflect the known addresses of=20 the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least the MAC=20 address of the neighbor. Message-TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Maximum Data Rate TLV (optional) - Current Data Rate TLV (optional) - Latency TLV (optional) - Expected Forwarding Time TLV (optional) - Resources TLV (optional) - Relative Link Quality TLV (optional) DLEP Order: Neighbor Down =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= The Neighbor Down is sent by the DLEP-Interface when a new neighbor is=20 detected on the network. It MUST contain a single Address with the Address Type "MAC" with the=20 network mac address of the former neighbor. Message-TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Status TLV (optional) DLEP Order: Neighbor Update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The Neighbor Update is sent by the DLEP-Interface when the link=20 characteristics to the neighbor change. It MUST contain a single Address with the Address Type "MAC" with the=20 network mac address of the neighbor. Message-TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Maximum Data Rate TLV (optional) - Current Data Rate TLV (optional) - Latency TLV (optional) - Expected Forwarding Time TLV (optional) - Resources TLV (optional) - Relative Link Quality TLV (optional) DLEP-Order: Neighbor Address Update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Neighbor Address Update is sent by the DLEP-Interface when the known = addresses of a neighbor change. It CAN contain multiple addresses which reflect the known addresses of=20 the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least the MAC=20 address of the neighbor. Message-TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) DLEP-Order: Message ACK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Message ACK is sent as a response to a received DLEP message (all=20 orders except Peer Discovery, Heartbeat and Message ACK itself). Message-TLVs: - DLEP-Order TLV (mandatory) - Identification TLV (optional) - Status TLV (mandatory) - Reference TLV (mandatory) Necessary IANA Registrations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Message Types ------------- +-------+-------+--------------------------------+ | Name | Type | Description | +-------+-------+--------------------------------+ | DLEP | TBD | Interface-Router communication | +-------+-------+--------------------------------+ Message-Type specific TLV Types ------------------------------- +--------------------+-------+-------+--------+------------------------+ | Name | Type | Type- | Value | Description | | | | Ext. | Length | | +--------------------+-------+-------+--------+------------------------+ | Identification | TBD | 0 | 8 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ | Version | TBD | 0 | 4 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ | Peer Type | TBD | 0 | 1-80 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ | DLEP-Order | TBD | 0 | 0 | Peer Discovery | | DLEP-Order | TBD | 1 | 0 | Peer Offer | | DLEP-Order | TBD | 2 | 0 | Peer Termination | | DLEP-Order | TBD | 3 | 0 | Peer Update | | DLEP-Order | TBD | 4 | 0 | Link Characteristics | | | | | | Request | | DLEP-Order | TBD | 5 | 0 | Heartbeat | | DLEP-Order | TBD | 6 | 0 | Neighbor Up | | DLEP-Order | TBD | 7 | 0 | Neighbor Down | | DLEP-Order | TBD | 8 | 0 | Neighbor Update | | DLEP-Order | TBD | 9 | 0 | Neighbor Addr. Update | | DLEP-Order | TBD | 10 | 0 | Message ACK | +--------------------+-------+-------+--------+------------------------+ | Version | TBD | 0 | 2 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ | Status | TBD | 0 | 1 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ | Reference | TBD | 0 | 3 | Reference to a | | | | | | different message. | | | | | | The value contains | | | | | | the order of the | | | | | | original message and | | | | | | its sequence number | +--------------------+-------+-------+--------+------------------------+ | Heartbeat Interval | TDB | 0 | 1 | Interval between | | | | | | Heartbeats. Value see | | | | | | RFC 5497, Section 6.1 | +--------------------+-------+-------+--------+------------------------+ | Heartbeat Validity | TBD | 0 | 1 | Validity time of | | | | | | Heartbeats. Value see | | | | | | RFC 5497, Section 6.1 | +--------------------+-------+-------+--------+------------------------+ |Maximum Data Rate | TBD | 0 | 8 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ |Current Data Rate | TBD | 0 | 8 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ |Exp. Forward Time | TBD | 0 | 4 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ |Latency | TBD | 0 | 2 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ |Resources | TBD | 0 | 1 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ |Relative Link Qual. | TBD | 0 | 1 | see Draft 2 | +--------------------+-------+-------+--------+------------------------+ Message-Type specific Address Block TLV Types --------------------------------------------- +--------------------+-------+-------+--------+------------------------+ | Name | Type | Type- | Value | Description | | | | Ext. | Length | | +--------------------+-------+-------+--------+------------------------+ | Address Type | TBD | 0 | 0 | This is a 6 byte | | | | | | MAC address | | Address Type | TBD | 1 | 0 | This is a 4 byte | | | | | | IPv4 address | | Address Type | TBD | 2 | 0 | This is a 16 byte | | | | | | IPv6 address | +--------------------+-------+-------+--------+------------------------+ | Address Operation | TBD | 0 | 0 | New/existing address | | Address Operation | TBD | 1 | 0 | Withdrawn address | +--------------------+-------+-------+--------+------------------------+ On 03/15/2012 07:59 PM, Stan Ratliff wrote: > I'll be interested to see the more complete explanation. It sounds to m= e > like you're talking about a "latency message", which would be unwieldy,= > IMO. > > regards, > Stan --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms070803000000020804090905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjAzMTYxMjI2MDVaMCMGCSqGSIb3DQEJBDEWBBSbp1CuPVydbUafiscKS0CDXixHmzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCY1jwg76FiIv7bahGCBbWDXiLuq5RdpIPdxntbeUKr4oIM4vV8mIb4m0JHOr8t DtG8RvssmULSgZMNhyKAPcXTos6apWItGxZRRlBH5OR97+ErWrRYszU3xFM8Vredd6qTxDY0 l3bgsgzHZEYoNHVM38eC5TUWiZP9WMuHGahIEFamlVi7t6LNbxRs+Kv5J5iAMGMskS61fZZ9 hglLHeJvCvx0JEQMcnG9mybDBxmCS0T5n05+u4+H4H5sBiPiZ+Yn/e/ePbEw06Yf4hmWSzoM hQvFeoc4gT9mN09ZDrdcxajl7IH164/zYki2aGX9a+9HHC+/nlG6TV7TcuO8cSJoAAAAAAAA --------------ms070803000000020804090905-- From sratliff@cisco.com Fri Mar 16 07:17:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A3B21F86D7 for ; Fri, 16 Mar 2012 07:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTZIHugkdJXh for ; Fri, 16 Mar 2012 07:17:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 159C521F86D4 for ; Fri, 16 Mar 2012 07:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=16398; q=dns/txt; s=iport; t=1331907468; x=1333117068; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=UQbmAKZaMrB7MyBg73eekmUftr6se1U6AxjB1plXlWA=; b=OXIpbZru6yDOA2H6V2LCUB7eHpuiH3afL/K1vGjWoAJb/zYXXrUL3Ice s1Mei++UWMaXf/ldKePqn6wwZhI/f4Ck19N2uJNvi6LRNNTXPkbijnB1/ bhdeTTemOGGcu/xq/LnH0c3kfsEoHab2X3zCes7sgCUA05EKWaZm2JozM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMpKY0+tJXHB/2dsb2JhbABCtjaBB4IJAQEBAwESASVBBQsLGCcHRhEGEyKHYwWadZ8dikaFCUtjBJVmjj+BaIMCgUA X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208";a="67065278" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 16 Mar 2012 14:17:47 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2GEHlxE006279; Fri, 16 Mar 2012 14:17:47 GMT Message-Id: From: Stan Ratliff To: Henning Rogge In-Reply-To: <4F633154.4070404@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Mar 2012 10:17:47 -0400 References: <4F61BBAB.6070600@fkie.fraunhofer.de> <0EAC6016-E342-4DFE-87C6-A6E0DCD141AB@cisco.com>

<49601379-4688-4BA6-BB4C-E57385B5BF9D@cisco.com> <5426CEA6-63FA-43BD-A24E-009EB9E2A563@cisco.com> <4F633154.4070404@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: Christoph Barz , manet@ietf.org Subject: Re: [manet] First feedback on DLEP draft 2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:17:51 -0000 Henning, ACK. Give me a day or two to study. Regards, Stan On Mar 16, 2012, at 8:25 AM, Henning Rogge wrote: > Hello, > > I will try to describe my concept of using DLEP without sub-TLVs. =20 > The mail became a little bit longer than I planned, but I wanted to =20= > explain the idea detailed enough. > > First a few ideas I used in the following text: > > - I would suggest using other words than server/client for the DLEP =20= > peers, because they are not intuitive to understand. My suggestion =20 > would be using DLEP-Interface for the former client and DLEP-Router =20= > for the former server. This will describe the default use case quite =20= > nicely. > > - I am not sure how the Detached Peer Discovery should work, because =20= > DLEP does not specify communication between multiple DLEP-Interfaces. > > - I skipped the Credit Grant scheme in this writeup, because I am =20 > not sure about its details. > > - I also put together all ACK messages into a single Order type, =20 > which simplifies the protocol description. > > - I think there are more options for simplification, but we can =20 > discuss them later. > > > DLEP Messages > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Each DLEP command/order is contained in a single RFC 5444 message =20 > with the message type "DLEP". Each of this messages MUST contain a =20 > message sequence number as specified in RFC 5444, Chapter 5.2. =20 > Message sequence numbers MUST be increased by each message of a peer =20= > and use the range of 0-65535. > > The address length of a DLEP message SHOULD be set to 16, to allow =20 > MAC, IPv4 and IPv6 addresses (and mixture of all three). If the DLEP =20= > peer does not support IPv6, is CAN set the address length to 6. > > DLEP messages CAN contain one or more addresses of different types. =20= > Each of these addresses MUST contain a "Address Type" TLV, which =20 > describes the number of used bytes of the RFC 5444 address, =20 > beginning with the first byte. The rest of the address MUST be =20 > padded with zero bytes, which can be compressed with the =20 > ahaszerotail option of the address block (see RFC 5444, Section 5.3). > > All custom DLEP message and address TLVs MUST be allocated from the =20= > Message-Type specific id range as defined in RFC 5444, chapter 6.1. > > Each DLEP message MUST contain a "DLEP-Order" message-TLV, which =20 > extension type specifies the order the message. > > Each DLEP message CAN contain an "Identification" message-TLV, if =20 > the underlaying transport mechanism does not allow DLEP to =20 > distinguish between endpoints of the router-interface communication. > > Each DLEP message CAN contain a "Peer Type" message-TLV, which =20 > describes the peer of the DLEP communication with a human readable =20 > identification string. > > If a DLEP message is a response to a former message of its peer, it =20= > MUST contain a "Reference" message-TLV, which describes the order of =20= > the referred message and its message sequence number. > > > > > DLEP Order: Peer Discovery > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > The Peer Discovery is sent by the DLEP-Interface to announce its =20 > existence to DLEP-Routers on its local interface. > > It CAN announce the interval and validity time of the heartbeat of =20 > the Router. > > Message TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Version TLV (optional) > - Peer Type TLV (optional) > - Heartbeat Interval TLV (optional) > - Heartbeat Validity Time TLV (optional) > > > DLEP Order: Peer Offer > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Peer Offer is sent by the DLEP-Router to acknowledge the =20 > presence of the DLEP-Interface and setup a session with the Interface. > > It CAN announce the interval and validity time of the heartbeat of =20 > the Router. > > Message TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Version TLV (optional) > - Peer Type TLV (optional) > - Heartbeat Interval TLV (optional) > - Heartbeat Validity Time TLV (optional) > > > DLEP Order: Peer Termination > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > The Peer Update CAN be sent by both the DLEP-Router and the DLEP-=20 > Interface to signal that it considers the session terminated. > > If the session was terminated because of a message by the peer, this =20= > message should contain a Status TLV. > > Message TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Status TLV (optional) > > > DLEP Order: Peer Update > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Peer Update CAN be sent by both the DLEP-Router and the DLEP-=20 > Interface to update some global data of the peer. > > The Peer Update message of the DLEP-Router CAN contain addresses =20 > with address TLVs to reflect a local address change. > > The Peer Update message of the DLEP-Interface CAN contain metric =20 > TLVs to reflect global changes of its connected network link. > > Message TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Current Data Rate TLV (optional for DLEP-Interface) > - Maximum Data Rate TLV (optional for DLEP-Interface) > - Latency TLV (optional for DLEP-Interface) > - Expected Forwarding Time TLV (optional for DLEP-Interface) > - Resources TLV (optional for DLEP-Interface) > - Relative Link Quality TLV (optional for DLEP-Interface) > > > DLEP Order: Link Characteristics Request > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Link Characteristics Request is sent by the DLEP-Router to =20 > request a change in the Peers interface. > > It CAN contain a single Address with the Address Type "MAC" to =20 > request a change of the network mac address of the peer. > > Message TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Current Data Rate TLV (optional for DLEP-Interface) > > > DLEP Order: Heartbeat > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Heartbeat CAN be sent by both the DLEP-Router and the DLEP-=20 > Interface. > > Message-TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - INTERVAL TIME TLV (optional, see RFC 5497, Section 9.2) > - VALIDITY_TIME TLV (optional, see RFC 5497, Section 9.2) > > > DLEP Order: Neighbor Up > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Neighbor Up is sent by the DLEP-Interface when a new neighbor is =20= > detected on the network. > > It CAN contain multiple addresses which reflect the known addresses =20= > of the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least =20 > the MAC address of the neighbor. > > Message-TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Maximum Data Rate TLV (optional) > - Current Data Rate TLV (optional) > - Latency TLV (optional) > - Expected Forwarding Time TLV (optional) > - Resources TLV (optional) > - Relative Link Quality TLV (optional) > > > DLEP Order: Neighbor Down > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > The Neighbor Down is sent by the DLEP-Interface when a new neighbor =20= > is detected on the network. > > It MUST contain a single Address with the Address Type "MAC" with =20 > the network mac address of the former neighbor. > > Message-TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Status TLV (optional) > > > DLEP Order: Neighbor Update > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > The Neighbor Update is sent by the DLEP-Interface when the link =20 > characteristics to the neighbor change. > > It MUST contain a single Address with the Address Type "MAC" with =20 > the network mac address of the neighbor. > > Message-TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Maximum Data Rate TLV (optional) > - Current Data Rate TLV (optional) > - Latency TLV (optional) > - Expected Forwarding Time TLV (optional) > - Resources TLV (optional) > - Relative Link Quality TLV (optional) > > > DLEP-Order: Neighbor Address Update > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Neighbor Address Update is sent by the DLEP-Interface when the =20 > known addresses of a neighbor change. > > It CAN contain multiple addresses which reflect the known addresses =20= > of the neighbor (MAC, IPv4 and/or IPv6). It MUST contain at least =20 > the MAC address of the neighbor. > > Message-TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > > > DLEP-Order: Message ACK > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The Message ACK is sent as a response to a received DLEP message =20 > (all orders except Peer Discovery, Heartbeat and Message ACK itself). > > Message-TLVs: > - DLEP-Order TLV (mandatory) > - Identification TLV (optional) > - Status TLV (mandatory) > - Reference TLV (mandatory) > > > > Necessary IANA Registrations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > Message Types > ------------- > > +-------+-------+--------------------------------+ > | Name | Type | Description | > +-------+-------+--------------------------------+ > | DLEP | TBD | Interface-Router communication | > +-------+-------+--------------------------------+ > > > > Message-Type specific TLV Types > ------------------------------- > > +--------------------+-------+-------+--------=20 > +------------------------+ > | Name | Type | Type- | Value | =20 > Description | > | | | Ext. | Length =20 > | | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Identification | TBD | 0 | 8 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Version | TBD | 0 | 4 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Peer Type | TBD | 0 | 1-80 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > | DLEP-Order | TBD | 0 | 0 | Peer =20 > Discovery | > | DLEP-Order | TBD | 1 | 0 | Peer =20 > Offer | > | DLEP-Order | TBD | 2 | 0 | Peer =20 > Termination | > | DLEP-Order | TBD | 3 | 0 | Peer =20 > Update | > | DLEP-Order | TBD | 4 | 0 | Link =20 > Characteristics | > | | | | | =20 > Request | > | DLEP-Order | TBD | 5 | 0 | =20 > Heartbeat | > | DLEP-Order | TBD | 6 | 0 | Neighbor =20 > Up | > | DLEP-Order | TBD | 7 | 0 | Neighbor =20 > Down | > | DLEP-Order | TBD | 8 | 0 | Neighbor =20 > Update | > | DLEP-Order | TBD | 9 | 0 | Neighbor Addr. =20 > Update | > | DLEP-Order | TBD | 10 | 0 | Message =20 > ACK | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Version | TBD | 0 | 2 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Status | TBD | 0 | 1 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Reference | TBD | 0 | 3 | Reference to =20 > a | > | | | | | different =20 > message. | > | | | | | The value =20 > contains | > | | | | | the order of =20 > the | > | | | | | original message =20 > and | > | | | | | its sequence =20 > number | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Heartbeat Interval | TDB | 0 | 1 | Interval =20 > between | > | | | | | Heartbeats. Value =20 > see | > | | | | | RFC 5497, Section =20 > 6.1 | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Heartbeat Validity | TBD | 0 | 1 | Validity time =20 > of | > | | | | | Heartbeats. Value =20 > see | > | | | | | RFC 5497, Section =20 > 6.1 | > +--------------------+-------+-------+--------=20 > +------------------------+ > |Maximum Data Rate | TBD | 0 | 8 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > |Current Data Rate | TBD | 0 | 8 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > |Exp. Forward Time | TBD | 0 | 4 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > |Latency | TBD | 0 | 2 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > |Resources | TBD | 0 | 1 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > |Relative Link Qual. | TBD | 0 | 1 | see Draft =20 > 2 | > +--------------------+-------+-------+--------=20 > +------------------------+ > > > > Message-Type specific Address Block TLV Types > --------------------------------------------- > > +--------------------+-------+-------+--------=20 > +------------------------+ > | Name | Type | Type- | Value | =20 > Description | > | | | Ext. | Length =20 > | | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Address Type | TBD | 0 | 0 | This is a 6 =20 > byte | > | | | | | MAC =20 > address | > | Address Type | TBD | 1 | 0 | This is a 4 =20 > byte | > | | | | | IPv4 =20 > address | > | Address Type | TBD | 2 | 0 | This is a 16 =20 > byte | > | | | | | IPv6 =20 > address | > +--------------------+-------+-------+--------=20 > +------------------------+ > | Address Operation | TBD | 0 | 0 | New/existing =20 > address | > | Address Operation | TBD | 1 | 0 | Withdrawn =20 > address | > +--------------------+-------+-------+--------=20 > +------------------------+ > > On 03/15/2012 07:59 PM, Stan Ratliff wrote: >> I'll be interested to see the more complete explanation. It sounds =20= >> to me >> like you're talking about a "latency message", which would be =20 >> unwieldy, >> IMO. >> >> regards, >> Stan > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > From iesg-secretary@ietf.org Mon Mar 19 08:36:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663C21F87AD; Mon, 19 Mar 2012 08:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7dqk2uK+G3q; Mon, 19 Mar 2012 08:36:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6056B21F87D3; Mon, 19 Mar 2012 08:36:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120319153614.7853.77204.idtracker@ietfa.amsl.com> Date: Mon, 19 Mar 2012 08:36:14 -0700 Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Document Action: 'Simplified Multicast Forwarding' to Experimental RFC (draft-ietf-manet-smf-14.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:36:15 -0000 The IESG has approved the following document: - 'Simplified Multicast Forwarding' (draft-ietf-manet-smf-14.txt) as an Experimental RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-smf/ Technical Summary This document specifies some simple mechanisms to distribute multicast data packets within a Mobile Ad-hoc Network (MANET). This document provides basic and simple multicast forwarding that can complement the on-going unicast routing protocol efforts of the MANET working group. Additionally, this document describes several different reduced relay set algorithms that can be used to make multicast dissemination more efficient. Working Group Summary There were no issues in the WG process. The I-D has progressed very slowly since WG lsat call as updates to address WG last call comments and to satisfy AD review have been slow. Protocol Quality This is intended for publication as an Experimental RFC. Several interoperable implementations of SMF exist; although only one is available. Note: that several of the methods laid out in SMF have been included in many MANET protocols and their implementations. Personnel Stan Ratliff (sratliff@cisco.com) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From ulrich@herberg.name Mon Mar 19 13:20:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EDD21E8013 for ; Mon, 19 Mar 2012 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJGJVwt4zehe for ; Mon, 19 Mar 2012 13:20:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0927321E800C for ; Mon, 19 Mar 2012 13:20:13 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1387480pbb.31 for ; Mon, 19 Mar 2012 13:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NJqkHIXZ+TtbEPvt/Yh6E/UDftmoBHszRntJvsHhH/o=; b=qTJ68vNNzlDYa8wEJVFbW0FVeMHF4QUMlu7CoOeiuxiis1MO58ZYmdsT5yTGtNuI0+ LyqX4Rd5SE99BV/zgtSv81qZpE4gyZHRx0N5vfsnCgHPJO58Bxdl1zoxlrRqmX6T1Qkk QseuwJWtkPy/0FNvG0oum0EK1phU9InyHtRaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=NJqkHIXZ+TtbEPvt/Yh6E/UDftmoBHszRntJvsHhH/o=; b=Dwr/qyuijeePzauTl1ooS+cLxX4uhOOFjkeV9Efh+0rOI7u2eCEmMwEmT21N8N56Kh NHKfwUJ4yYNdviwrxh1rgIpxD4hyzae8A7mzxLdocVHt+C090x+WemUkxU5sZ7Yt825R CmB72QUEjkNyb/XY7EGfJJ5XRc6SUUWBezyNclFG1jb4Dd84Ow0ebR4wB0a9dbbBXHUk S8+Hldnbb5+S7REfHG4H4DpmEiiWYd5EnyRCSwkUdUX8IBovOI8Ueh8COM9pPH7zkAbt WPPXFn9755KOO/S7o1DUQlWdVAQ+xiuQQQxxA+ZFZapStUdEm6LQCdufDA0qujj6zWTj jc/g== MIME-Version: 1.0 Received: by 10.68.221.106 with SMTP id qd10mr28071099pbc.161.1332188413508; Mon, 19 Mar 2012 13:20:13 -0700 (PDT) Received: by 10.142.70.11 with HTTP; Mon, 19 Mar 2012 13:20:13 -0700 (PDT) Date: Mon, 19 Mar 2012 13:20:13 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff25500293cb104bb9e4922 X-Gm-Message-State: ALoCoQnmqEnyS7o0NMYlXjXkmDAdiYMhUrgoLQB2LoBZJq6bV7TzKi7pbB4U1mv9dlAy2FLpwTdh Cc: manet-chairs@tools.ietf.org Subject: [manet] Updated agenda X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:20:18 -0000 --e89a8ff25500293cb104bb9e4922 Content-Type: text/plain; charset=ISO-8859-1 Hi, we have updated the agenda on: http://www.ietf.org/proceedings/83/agenda/agenda-83-manet.txt As we have more discussions than usual, we have to keep discussions within time limits, which are added to the agenda. If any of the presenters needs more (or less) time, please send an email to the chairs. Best regards Ulrich --e89a8ff25500293cb104bb9e4922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

we have updated the agenda on:
http://www.ietf.org/proceedings= /83/agenda/agenda-83-manet.txt

As we have more discussions than = usual, we have to keep discussions within time limits, which are added to t= he agenda. If any of the presenters needs more (or less) time, please send = an email to the chairs.

Best regards
Ulrich
--e89a8ff25500293cb104bb9e4922-- From ulrich@herberg.name Mon Mar 19 17:04:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E427A21F8726 for ; Mon, 19 Mar 2012 17:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUR0vrIRHG7k for ; Mon, 19 Mar 2012 17:04:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F112B21F8723 for ; Mon, 19 Mar 2012 17:04:46 -0700 (PDT) Received: by lbol12 with SMTP id l12so4312266lbo.31 for ; Mon, 19 Mar 2012 17:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=bhqWC1X5X5MK7N8JGzb94bDMER4t9h1MUHzCyXi+RsY=; b=RN4X4j7Hl5/Mb5MzARIlvV3Hb/e4lFeWd+ineAu2Jmb8G9wb2H+CNBNq1wqdvvvbV0 H0p5NeS3AKs0UUvQqBv7KKQt/8y6ASCQJpoKM9bK1a5WvRXawe4pC8+XMtmfuGgO8M92 xlTfKUhHvF/2rIM1qFIowvEJHaE/6g5+vH1e4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=bhqWC1X5X5MK7N8JGzb94bDMER4t9h1MUHzCyXi+RsY=; b=RVooWhFaGz/3bxr0Qf8y+4OBDBdFzf6sE4jUK3rSPNRncjNl1SA8zyTuUXRUVnoWrL sKTbx6i8Yzv5gXFmzphqNRUFGW9ooLpLE8E42zQd/ZgZlQAj6XeS5Z24+G+Q8HOvEHtt VlAuli0Jq7RQETUkJVzPSrHSsngFkyDBkdcba6ImI5XFahuuHDOWjwlVSdP+6bXEmoZN 2yqEK3vuvEefPKwvq3YvI2neH9samh8w1LmBUvHKAg5xs1/kaOqohPtGq94yAhpTEmXE Qff2Na0VfPc5jBftiuQkDZjW/BEX1QuQ8GV0c9FpjPrgDs6vRudwKf+d/jdXfI6WD019 tWoA== MIME-Version: 1.0 Received: by 10.112.29.166 with SMTP id l6mr5264679lbh.78.1332201885969; Mon, 19 Mar 2012 17:04:45 -0700 (PDT) Received: by 10.112.148.100 with HTTP; Mon, 19 Mar 2012 17:04:45 -0700 (PDT) Date: Mon, 19 Mar 2012 17:04:45 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d040169632eac9604bba16ce6 X-Gm-Message-State: ALoCoQkDUFP/yFZ1LqnvDp7zZ7kb7reNwysNtpbA4lcuW4ZsSJ+sd9U+xnVDLZxnIqDEEoXyjbVs Subject: [manet] Slides for MANET meeting X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:04:48 -0000 --f46d040169632eac9604bba16ce6 Content-Type: text/plain; charset=ISO-8859-1 Hi, for those who present during the MANET meeting: Please send your slides in time before the meeting (ideally until Monday of the IETF, but no later than Wednesday). As we have many items on the list, please keep the slides concise and short. Pdf format is preferred. Thanks Ulrich --f46d040169632eac9604bba16ce6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

for those who present during the MANET meeting: Please send your= slides in time before the meeting (ideally until Monday of the IETF, but n= o later than Wednesday). As we have many items on the list, please keep the= slides concise and short. Pdf format is preferred.

Thanks
Ulrich
--f46d040169632eac9604bba16ce6-- From abdussalambaryun@gmail.com Tue Mar 20 06:01:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A458921F8659 for ; Tue, 20 Mar 2012 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuRZ2yxzURvq for ; Tue, 20 Mar 2012 06:01:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C95421F85F8 for ; Tue, 20 Mar 2012 06:01:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1195384vbb.31 for ; Tue, 20 Mar 2012 06:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3a8fMw7Y0gcI1d0KbNu/Tc9Dq768xwsbVaTd0aOonQ8=; b=IIU2O9uBmaTg7bO8yGXmMZBnMOdSOn9TlopsOAot4G4BZJwH7y5AGlwMHPeXpOE533 AMy0q8lgFn1cXbdYJpuDqd2U0IzvWZbooV1LsLUeBG52C3ienyqxUzLEpNaxkJdNzidr efIDgoFUgwUFK5advxnKDH4kWGBnUKbmBpZ6c+wt2c3od9MISUFT4GtO+zVCwaqyGqix nqHGE+UAVaupT7sMVmsLK+WjtHA18F4cnztDmiD3XuMSiIN73RvjJWm+Avnr1LuVYnyG fViY2YfeRr9zeUoc/3Gke8G3syxwzabZrZQNveC42MGyXiZyhewC7GvQth7KScCJ/nrg ObEA== MIME-Version: 1.0 Received: by 10.220.3.10 with SMTP id 10mr6576460vcl.23.1332248467200; Tue, 20 Mar 2012 06:01:07 -0700 (PDT) Received: by 10.220.227.132 with HTTP; Tue, 20 Mar 2012 06:01:07 -0700 (PDT) Date: Tue, 20 Mar 2012 13:01:07 +0000 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=000325575576a3dcf204bbac44e7 X-Mailman-Approved-At: Tue, 20 Mar 2012 06:49:18 -0700 Subject: [manet] Does AODVv2 updates DYMO? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:01:08 -0000 --000325575576a3dcf204bbac44e7 Content-Type: text/plain; charset=ISO-8859-1 Hi, Reviewing the draft of AODVv2 (previously DYMO), I think the title confused me because I thought that AODVv2 is a new version of the AODV RFC3561, but I see that it is an update to the DYMO draft. In the introduction there is no reference to AODV FRC3561, which now AODVv2 has the similar name, it was not confusing in the previous DYMO_draft. I think if mentioning RFC3561 in draft AODVv2 introduction is preferable, to clarify its relationship with this work. The only related reference was seen in section 9 and 5.3.1 However, There are two questions I didn't understand: 1- Will we see a new draft or version of DYMO or not? 2- Is AODVv2 another routing protocol than RFC 3561? Please clarify, Abdussalam ICRC, University of Glamorgan, UK --000325575576a3dcf204bbac44e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Reviewing the draft of AODVv2 (previously DYMO), I think the title con= fused me because I thought that=A0AODVv2 is a new version of the AODV RFC35= 61, but I see that it is an update to the DYMO draft.

=A0

In the introduction there is no reference to AODV FRC3561, which now A= ODVv2 has the similar name, it was not confusing in the previous DYMO_draft= . I think if mentioning=A0RFC3561=A0=A0in draft=A0AODVv2=A0 introduction is= preferable,=A0to clarify its relationship with this work.

=A0

The only related reference was seen in section 9 and 5.3.1

=A0

However, There are two questions I didn't understand:

1- Will we=A0see a new draft or version of DYMO or not?

2- Is AODVv2 another routing protocol than RFC 3561? Please clarify,

=A0

Abdussalam

ICRC, University of Glamorgan, UK

=A0

--000325575576a3dcf204bbac44e7-- From internet-drafts@ietf.org Mon Mar 26 06:18:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1916321F868A; Mon, 26 Mar 2012 06:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIjpSsnw3-Ia; Mon, 26 Mar 2012 06:18:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028D21E8097; Mon, 26 Mar 2012 06:18:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326131828.3218.8887.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 06:18:28 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-12.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:18:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-12.txt Pages : 68 Date : 2012-03-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-12.txt From robert.g.cole.civ@mail.mil Mon Mar 26 09:33:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCD021E8044 for ; Mon, 26 Mar 2012 09:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTMYYscAwxnD for ; Mon, 26 Mar 2012 09:32:54 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0ED21F8599 for ; Mon, 26 Mar 2012 09:32:53 -0700 (PDT) Received: from UCOLHP3Q.easf.csd.disa.mil (131.64.100.156) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 26 Mar 2012 16:32:45 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.78]) by UCOLHP3Q.easf.csd.disa.mil ([1.211.145.152]) with mapi id 14.01.0339.001; Mon, 26 Mar 2012 16:32:45 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: "'manet@ietf.org'" , "'adrian@olddog.co.uk'" Thread-Topic: Response to Adrian's NHDP-MIB comments Thread-Index: AQHNC2zHdESsAJFuXkiBvRv8qCKN2ZZ8xUuY Date: Mon, 26 Mar 2012 16:32:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] Fw: Response to Adrian's NHDP-MIB comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:33:03 -0000 Adrian, Joe, Stan, This should help in your decision for next step. =20 Thanks, Bob and Ulrich=20 ----- Original Message ----- From: Robert G Cole [mailto:rgcole01@comcast.net] Sent: Monday, March 26, 2012 04:23 PM=0A= To: Cole, Robert G CIV USARMY CERDEC (US) Subject: Response to Adrian's NHDP-MIB comments Adrian, Thank you very much for this thorough review. This is much appreciated! Please see our comments below: > State changed to AD Evaluation::Revised ID Needed from Publication > RequestedAD review... > > Hi, > > Many apologies for a delayed AD review of this document. I love MIB > modules deeply, but I did want to clear out the other MANET documents > from the pipe before working on this one. > > As usual, the purpose of my review is to catch and clean up issues that > might show later in the process, thereby saving community and IESG > review effort, and giving the document a smoother ride through the > system and a greater likelihood of approval. > > This is a substantial document and is generally solid. The number of > comments reflects the fact that writing MIB modules is a real back- > breaker. I think it is important to note that I did not have any > concerns about the structure of the module or the tables (except one > small suggestion about moving the TCs into a separate module). Most > of the comments are at the level of MIB nits. > > All comments are, of course, up for discussion and debate. > > I think we need a new revision at this point. Then we can go to MIB > Doctor review and IETF last call at the same time. > > Many thanks, > Adrian > > --- > > 5.1.3.1 > > The majority of critical events occur when NHDP is enabled on a > router, at which time the symmetric neighbors and two-hop neighbors > of the NHDP router are discovered. > > I think we can clarify this because there are currently two > interpretations: > > - when NHDP is operational (enabled) > - when NHDP is initiated (enabled or the first time) > > >From context, I think you mean... > > The majority of critical events occur when NHDP is first enabled on a > router, at which time the symmetric neighbors and two-hop neighbors > of the NHDP router are discovered. > Yes, agreed. > > --- > > 5.1.3.1 > > To avoid unnecessary notifications, a router should not > originate expected notifications until a certain time interval has > elapsed, which is to be predefined by the network manager. > > 1. Is this "SHOULD NOT"? > Yes. > 2. Is there a recommended default for such a timer value? I think you > should give one if you can. > How about this: It is RECOMMENDED that this time interval is at least 3 x HELLO_INTERVAL, so that symmetric neighbors are discovered. > > --- > > 5.1.3.2 > > Appropriate values for the window time and upper bound are to be > selected by the network manager and depend on the deployment of the > MANET. > > I believe you here, but I would welcome some more guidance for the > implementer and the deployer. Is there anything you can add? > We added that: If NHDP is deployed on a lossy, wireless medium, sending too many notifications in a short time interval may lead to collisions and dropped packets. In particular, in dense deployments of NHDP routers (i.e. where each router has many neighbors), a change of the local topology may trigger many notifications at the same time. [RFC4750] recommends "7 notifications with a window time of 10 seconds" as upper bound. As NHDP is expected to be deployed in more lossy channels than OSPF, it is RECOMMENDED to choose a lower threshold for the number of notifications per time than that. > > --- > > 5.1.3.3 > > OLD > Similar to the according mechanism in [RFC4750], only one > notification is sent per event. > NEW > Similar to the mechanism in [RFC4750], only one notification is sent > per event. > END > OK. > > --- > > Section 6 > > This section specifies the relationship of the MIB modules contained > > s/modules/module/ > OK. > > --- > > You have included Section 6.3 which is perfect. > In the light of this, there is a body of opinion amongst "MIB experts" > that citation notation should not be used in the body of the MIB > module. This is because the module will be ripped from the document > for compilation and passed around as a stand-alone piece of text. > > Thus, just take the square brackets out form the comments in the > IMPORT clauses. > > Make the same change to any Description and Reference clauses. > OK. > > --- > > Don't forget to make any necessary changes to the CONTACT-INFO clause. > I (Ulrich) have updated Stan's email address. I have agreement with Thomas = and my new employer to leave my old affiliation on this document. > > --- > > The copyright date in the MODULE-IDENTITY clause is a little out-of- > date. > OK, changed to 2012. > > --- > > For sound reasons, revisions of the MIB module posted in Internet-Drafts > are not considered as "Revisions". That is, per the boilerplate, it is > inappropriate to use Internet-Drafts as reference material or to cite > them other than as "work in progress. > > That means that the first revision of the MIB Module is the one that > gets published in the RFC. > > Can you tidy the Revision clauses so that there is only one, and it > applies to the RFC-that-will-be. The RFC Editor will fix up the date on > publication. > > Good point! Fixed. > --- > > NeighborIfIndex > > I'm not saying what you have is wrong, but why did you decide to not > assign this TC the Syntax InterfaceIndex? > We agree that this is somewhat unusual, but we keep this as is. However,=20 we did modify the TC Description to point out that this is not persistent between re-initializations. This is different from the semantics of the 'InterfaceIndex'. As NHDP process discover more about it's neighborhood it may in fact realize that what it originally thought were two interfaces on neighbors is in fact a single interface and thus needs to merge its understanding of the interfaces. > > --- > > For nhdpInterfaceTable I think it is necessary to say that when the > corresponding entry with ifIndex value is deleted from the Interface > Table, the entry in this table is automatically deleted. > OK, added. > > --- > > nhdpIfIndex has Syntax InterfaceIndexOrZero, but the Description says > "The ifIndex for this interface." > > Note that according to RFC 2863, ifIndex has Syntax InterfaceIndex. > > So you need to decide to either: > - change the Syntax of nhdpIfIndex > Changed to InterfaceIndex. > or > - add an explanation of what it means to have a zero value > > --- > > nhdpIfStatus > > I *think* it is more normal to write: > > DEFVAL { false(2) } > Done. > > --- > > nhdpInitialPending > > Given the constraint conditions described for this object, I don't > think it is appropriate to have a Default clause. That is, if the > constraining objects are not defaulted for whatever reason, then this > object cannot be allowed to default. > > This is correctly reflected in you making the object read-only, and we > should note that there is no value in assigning a Default for a read- > only object. > Agreed. > > --- > > Finding nhdpIfRowStatus and seeing the text talk about row creation, I > wondered why none of the objects in the row under the control of this > object have Max-Access read-create. What you have is legal, but it means > that the row is created with all the defaults in place and then can be > modified if the management application wants to. > > Since there is no equivalent of an adminStatus, this means that for a > while the row (and associated protocol elements) will operate with the > default values rather than the values the management application wanted > to set. > > Yes, in fact RFC2578 states " .. if any columnar object has 'read-create' ... then no other object (of the row) may have 'read-write' as max-access." So we maintained the RowStatus object in the entry and changed max-access to writable objects to 'read-create'. > --- > > The second paragraph of the description of nhdpLibLocalIfSetTable begins > "It consists of..." This is mildly ambiguous because the previous > paragraph ends with a sentence about nhdpIfIndex. > Changed "it" to "the Local Interface Set". > > --- > > nhdpLibLocalIfSetIpAddrType should contain a comment about the valid > values since I assume you don't support the full set defined for > InetAddressType. You can also constrain the interpretation of > nhdpLibLocalIfSetIpAddr according to nhdpLibLocalIfSetIpAddrType. > > You would write... > > nhdpLibLocalIfSetIpAddrType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The type of the nhdpLibLocalIfSetIpAddr > in the InetAddress MIB [RFC4001]. > > Only the values unknown(0), ipv4(1), and > ipv6(2) are supported." > REFERENCE > "[RFC6130]." > ::=3D { nhdpLibLocalIfSetEntry 1 } > OK, although we have included only ipv4(4) and ipv6(2)=20 for these objects. > > nhdpLibLocalIfSetIpAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "nhdpLibLocalIfSetAddr is an > address of an interface of > this router. > > This object is interpretted according to > the setting of nhdpLibLocalIfSetIpAddrType." > REFERENCE > "[RFC6130]." > OK. > > This will also need to show up in the conformance statements. You > write something like... > > OBJECT nhdpLibLocalIfSetIpAddrType > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > MIN-ACCESS read-only > DESCRIPTION "Only unknown(0), ipv4(1), and ipv6(2) support > is required." > > And similarly... > > OBJECT nhdpLibLocalIfSetIpAddr > SYNTAX InetAddress (SIZE(0|4|16)) > MIN-ACCESS read-only > DESCRIPTION "An implementation is only required to support > address sizes of: > 0 for address type unknown(0) > 4 for address type ipv4(1) > 16 for address type ipv6(2)." > So, we scoped the allowable address types to=20 'ipv4(4), ipv6(2)' and reflected this in the Description of this object and reflected in a statement in the Compliance Statements. Note, this comment also applies to the following objects: nhdpLibRemovedIfAddrSetIpAddrType and nhdpLibRemovedIfAddrSetIpAddr. We scoped these objects as well. > > Lastly, is the value zero allowed for nhdpLibLocalIfSetIpAddr? If so > you will need some text in its DESCRIPTION clause like... > > If this object is set to 0, the value of > nhdpLibLocalIfSetIpAddrType must be set to > unknown(0)." > > You would need to do this for all uses of InetAddress[Type] > As mentioned above; we have precluded type 'unknown(0)'. > > --- > > You need to do a general search and replace s/MIB/MIB module/ > There is only one MIB and this MIB module forms part of it. > OK. > For example... > > nhdpStateObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 2 } > > -- Two new constructs have been defined in this MIB for > -- indexing into the following > -- tables and indexing into other tables in other MIBs. > > --- > > Question... > > nhdpStateObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 2 } > > -- Two new constructs have been defined in this MIB for > -- indexing into the following > -- tables and indexing into other tables in other MIBs. > > 1. This text seems to come very late in the module. How about > relocating to be next to the definition of the "constructs"? > Yes, we have moved this text up to in-front of the TC definitions.=20 > > 2. I think s/constructs/Textual Conventions/ > Done. > > 3. If it is clear that you will use these TCs to index other > MIB modules, you should seriously consider putting them in > their own module. You can keep this new module in this > document, but making it a separate module makes imports from > other modules much more simple. > So, it is not clear at this time that we need or want to reuse these constructs. In the one case where we thought we might is in the OLSRv2-MIB draft. However, there we are planning to rewrite it to rely on AUGMENTS statements to define simple extensions to the existing associated Tables in NHDP. Hence, we have left the TC definitions within the NHDP-MIB module. We hope this is OK? > > --- > > nhdpUpTime could use a display hint clause. > We changed the semantics of this object per your comments below regarding the use of TimeStamp and sysUpTime. So now, this object holds the sysUptime at the time that the current NHDP process was initialized. > > --- > > nhdpInterfaceStateTable OBJECT-TYPE > SYNTAX SEQUENCE OF NhdpInterfaceStateEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "nhdpInterfaceStateTable lists state information > related to specific interfaces of this NHDP router. > The ifIndex is from the interfaces group > defined in the Interfaces Group MIB. > > Unless I am mistaken, you are not using ifIndex, but ndhpIfIndex. > So you should say... > > The value of ndhpIfIndex is an ifIndex from the > interfaces group defined in the Interfaces Group > MIB. > > Similarly nhdpInterfaceStateEntry (which is missing a REFERENCE clause. > OK. > > --- > > There is nothing wrong, IMHO, with using TimeTicks for nhdpUpTime and > nhdpIfStateUpTime. However, this places a burden on the implementation > rather than the agent. > > A common approach is to grab the sysUpTime value when the instance was > initialised, and to only report that. An agent that is interested in > the amount of time that the instance has been up, can read sysUpTime > and do the calculation itself. > > If you grab sysUpTime, you use the Textual Convention TimeStamp which > ironically has the Syntax TimeTicks. The difference is that it is frozen > rather than your usage which is rolling. > As mentioned above, we have converted the symantics of this (and other) objects to have SYNTAX TimeStamp and to hold the value of sysUpTime at the time of initialization. This also affacts the following objects in the MIB module: nhdpLibRemovedIfAddrSetIrTime and nhdpDiscNeighborNibNeighborSetUpTime . > > --- > > As I understand it, nhdpIibLinkSetLTime is a time in the future. I'm not > sure, butI don't think you are allowed to use TimeStamp like this > because it is supposed to report on an event that has already happened. > This may be a bit pettifogging and we should maybe make a list of > questions to ask the MIB Doctor. > We left the semantics of this object as a future time based upon the expected sysUpTime at which these entry objects expire. We add to the Description text to read: "nhdpIibLinkSetLTime specifies the sysUptime when to expire this Tuple and in which case MUST be removed. Upon expiration this entry in the 'nhdpIibLinkSetTable' should be removed." > > --- > > nhdpInterfacePerfTable etc. > > For you to think about depending on the interface speeds you think you > are supporting. The requirements on the use of 32-bit and 64-bit > counters copied from RFC 2863 are as follows: > > For interfaces that operate at 20,000,000 (20 million) bits per > second or less, 32-bit byte and packet counters MUST be supported. > For interfaces that operate faster than 20,000,000 bits/second, > and slower than 650,000,000 bits/second, 32-bit packet counters > MUST be supported and 64-bit octet counters MUST be supported. > For interfaces that operate at 650,000,000 bits/second or faster, > 64-bit packet counters AND 64-bit octet counters MUST be > supported. > We do not expect interface speeds in excess of 650,000,000 bits/second. In this case we are in compliance with the statement from RFC 2863. > > --- > > nhdpSetNotification OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(4)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 4-octet string serving as a bit map for > the notification events defined by the NHDP > notifications. This object is used to enable > and disable specific NHDP notifications where > a 1 in the bit field represents enabled. The > right-most bit (least significant) represents > notification 0. > > This object is persistent and when written > the entity SHOULD save the change to > non-volatile storage. > " > ::=3D { nhdpNotificationsControl 1 } > > I find the use of Octet String in this way a bit icky. It is, of course, > possible to represent the whole MIB module using Octet Strings, but we > don't. Did you consider and reject the BITS construct? It seems neater > and more explicit. > We pulled this object from the MIB module as we felt it was unnecessary to the operation of the module.=20 > > I also spent some time trying to work out which notification is > "notification 0" because the first notification listed is > { nhdpNotificationsObjects 1 } > These should start at '1'. > > --- > > Should the ChangeThreshold and ChangeWindow family of objects have > DEFVALs? > We have added DEFVALs and associated Descriptions for each of the=20 following NotificationGroup objects: nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow, nhdp2HopNbrStateChan= geThreshold, nhdp2HopNbrStateChangeWindow, nhdpIfRxBadPacketThreshold and nhdpIfRxBadPacketWindow. > > --- > > nhdpNbrState, nhdp2HopNbrState, and nhdpIfState are (correctly) > read-only. They shouldn't have DEFVALs defined because they report what > they report. > >=20 OK. > You might want to add to the Description... > > If the state of foo is unknown, an implementation should return bar(n) > > Or you might want to define specific "unknown" values to handle this, > We addressed this comment through addition Description, e.g., for the nhdpNbrState we have the following Description: "NHDP neighbor states. In NHDP, note that it is not necessary to remove Protocol Tuples from Protocol Sets at the exact time indicated, only to behave as if the Protocol Tuples were removed at that time. This case is indicated here as 'down(0)', all other cases being indicated as 'assymetric(1)' or 'symmetric(2)'. If down, the direct neighbor is also added to the nhdpNibLostNeighborSetTable." Comparable text was added to the nhdp2HopNbrState and nhdpIfState object descriptions. > > --- > > Really good job on the Security Considerations section! > Thanks! Ulrich and Bob From ulrich@herberg.name Wed Mar 28 00:36:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F329521F876A for ; Wed, 28 Mar 2012 00:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCtYxd52xfNw for ; Wed, 28 Mar 2012 00:36:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6021F8779 for ; Wed, 28 Mar 2012 00:36:17 -0700 (PDT) Received: by eaaq11 with SMTP id q11so172186eaa.31 for ; Wed, 28 Mar 2012 00:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=RLlm9siYkOS/uF9bU36yZoyRfbFdRTG+ynk8ig+b2Ho=; b=s6odmcEyxykIPsxHTYib/w2Ak7xkRyJqEs36+YMpRquHQi0e6i6vUQmFXQMnarMqog 7sOoG81q3CH+IswHZE5kx/8LfohHwiWPFOTLRpO99b48eqnMmuiub11I0+6yRke+fbD5 fdvAPGJ/xsF7FNYPLrmUM9FC5rEspE3fimWZ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version:x-gm-message-state; bh=RLlm9siYkOS/uF9bU36yZoyRfbFdRTG+ynk8ig+b2Ho=; b=HInyVm5mH8DA2TfMmxi7Gz8ddbC4xfk5L60dXaoUBFSCK7WMRc38NMUK/PoWEIPlbF WQlfd7WDKflRe6DGl5g5+hevmKcw9KG0S2e23R82JUjZKM2r1r4C1G2iiRNsAN0kxBX6 fTQuu/mi6QD8u53ugyy0rSHk2lfJn6mi0K7rvyeb10q2cyDX8fRlfCjhLDsOaMvl+k5C oPfHdz9llUuducd8hZWl4iI6Mqrit9N+z6zoarp9RQ/3RzGYrVFa9TD3RxG679InBO/a G+vhflrL/uxHPBVBq814FlX8rLA4UtV1s0MzuCtWLKsIBpLiBM2r7X3zws5MiVG3mT3U zokg== Received: by 10.213.2.201 with SMTP id 9mr1939366ebk.166.1332920176662; Wed, 28 Mar 2012 00:36:16 -0700 (PDT) Received: from ?IPv6:2001:df8::16:49f:1673:6e30:e994? ([2001:df8:0:16:49f:1673:6e30:e994]) by mx.google.com with ESMTPS id m55sm7516761eei.1.2012.03.28.00.36.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 00:36:15 -0700 (PDT) From: Ulrich Herberg Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9B176) Message-Id: <0CC725C7-75ED-4291-8874-BE4091092D79@herberg.name> Date: Wed, 28 Mar 2012 09:36:15 +0200 To: manet@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQnxSvRj42wMVoSpD7PKUqyQos+HEvZeUhwEcfiY3LOBm7yTIAAMtT7fHw76uYajdKxLqnmm Subject: [manet] Slides please! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:36:19 -0000 Hi, can all presenters please send the slides today? There are still several sli= de sets missing. Thanks Ulrich= From thomas.r.henderson@boeing.com Wed Mar 28 14:15:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE92B21E8097 for ; Wed, 28 Mar 2012 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.207 X-Spam-Level: X-Spam-Status: No, score=-107.207 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoC38OgLT+w6 for ; Wed, 28 Mar 2012 14:15:33 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 37E7F21E8040 for ; Wed, 28 Mar 2012 14:15:33 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q2SLFTDf012538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Mar 2012 14:15:30 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q2SLFT60028214; Wed, 28 Mar 2012 14:15:29 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q2SLEnlb026823 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Mar 2012 14:15:28 -0700 (PDT) Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 28 Mar 2012 14:15:20 -0700 From: "Henderson, Thomas R" To: "'Cheng, Bow-Nan - 0665 - MITLL'" Date: Wed, 28 Mar 2012 14:15:19 -0700 Thread-Topic: R2RI Framework and Requirements Thread-Index: AczoIJR4m04ho3GMT+uhB4jsRids5gk/HtiQ Message-ID: <758141CC3D829043A8C3164DD3D593EA1BCD163F01@XCH-NW-16V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] R2RI Framework and Requirements X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:15:34 -0000 Bow-Nan, I see that your draft is on the MANET agenda for tomorrow, and since I can'= t attend, I wanted to provide some feedback via the list. I previously voi= ced support for a draft like this and would be interested in working on it = in the future. I had a few high-level comments for starters. I think it would be helpful = to discuss some goals for this draft, in the context of the other specifica= tions in development or already published. Presently, the document seems t= o be requirements-oriented and states: 4. Requirements To evaluate the R2RI framework, any proposed R2RI protocols MUST satisfy= all requirements listed in the following subsections. However, I do not think this is a practical goal, since some radio-to-route= r protocols are already published and implemented that do not satisfy all o= f the stated requirements, and the requirements may not be universally appl= icable. I also did not understand what was meant by the phrase "To evaluat= e the R2RI framework,". I'm wondering whether the terminology could be re= laxed from "requirement" to "design criteria"? =20 I think it would also help to have some more discussion of the scope of app= licability (including expanding to satellite as Lloyd previously suggested,= and including perhaps a taxonomy of radio types of interest), functional g= oals or use cases, and how the existing specifications map to the design cr= iteria and functional goals. It seems that future vendors will have a numb= er of protocols to choose from, so some statement of applicability of each = of these protocols might be useful. Maybe future R2R protocol specificatio= ns could reference specific use cases in this draft. I also think it would help to sketch out what is the plan for providing a c= omplete specification for how to write a DLEP-enabled protocol, and how DLE= P may evolve in the future. The current DLEP draft is limited to the DLEP = layer and doesn't get into details such as encapsulation and security, but = a vendor would eventually need some kind of "DLEP over DTLS" or "DLEP over = Ethernet" specification to build to. Either this draft or the DLEP draft o= ught to describe how the modularity of DLEP will be handled by various spec= ifications. - Tom From thomas.r.henderson@boeing.com Wed Mar 28 14:16:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F4921E80EF for ; Wed, 28 Mar 2012 14:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.175 X-Spam-Level: X-Spam-Status: No, score=-107.175 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7RsW27bE9yc for ; Wed, 28 Mar 2012 14:16:52 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id AF6EB21E8040 for ; Wed, 28 Mar 2012 14:16:52 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q2SLGdTn010911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Mar 2012 14:16:40 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q2SLGdxk029529; Wed, 28 Mar 2012 14:16:39 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q2SLGd74029519 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Mar 2012 14:16:39 -0700 (PDT) Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 28 Mar 2012 14:16:39 -0700 From: "Henderson, Thomas R" To: Stan Ratliff Date: Wed, 28 Mar 2012 14:16:39 -0700 Thread-Topic: comments and questions on draft-ietf-manet-dlep-02 Thread-Index: Ac0NKBBvzWCgGVaxS8SefXTe2kvG4g== Message-ID: <758141CC3D829043A8C3164DD3D593EA1BCD163F02@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MANET IETF Subject: [manet] comments and questions on draft-ietf-manet-dlep-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:16:53 -0000 Stan, below please find some comments and questions on the latest DLEP draf= t. There are two classes of sessions - the first is identified as a 'peer session'. The peer session exists between a DLEP server and a DLEP client. I found (also in the R2RI draft) the use of 'peer' to be at odds with what = is basically an asymmetric, client/server relationship. I might suggest to= replace 'peer' with 'local'. The other type of DLEP session is referred to as a 'neighbor session'. Neighbor sessions can be instantiated by either the DLEP server or client, and represent an identifiable destination (i.e. an address) within the network. Examples of a destination would be a unicast address (for either a next-hop router, or for an end-station), or a multicast address. A DLEP neighbor session MUST exist for every destination that exists in the network. This description is somewhat unclear. What are the session endpoints (the = remote DLEP router or the local DLEP radio)? What happens if the MUST is n= ot satisfied? What is the definition of 'exists in the network' (I think t= his means the IP link bounded by the DLEP routers, but am not sure). The unsigned 16-bit Sequence Number rolls over at 65535 to 1. A Sequence Number of 0 is not valid. Why doesn't the sequence number wrap in the usual way? Can you please stat= e the reason in the draft, or else align it with RFC 5544? I saw that Ulri= ch had the same question (didn't notice a response to it). If used, credits are managed on a neighbor session basis; that is, separate credit counts are maintained for each neighbor session requiring the service. Credits do not apply to DLEP peer sessions. Why are credits also not applicable to peer sessions (as are the metrics)? = I'm imagining that a broadcast-based radio may want to advertise a credit = grant to all reachable radios, not on a neighbor-session basis. Regarding the credits (new in this draft version), is section 10.7 on the C= redit Window Status Sub-TLV also applicable to post-initialization updates?= Some consideration ought to be given to advertising a window rather than = (or in addition to) the incremental granting specified, to take away credit= previously granted (e.g. to pause the peer). I agree strongly with Ulrich's suggestion to move the elements of procedure= (message processing rules) out of the appendix and into normative text suc= h as done in RFC 6130. Some of the specification on message processing see= ms to be also embedded in the TLV and message descriptions at the moment. = I would also recommend consulting RFC 4101 for guidance on how to write the= high-level overview of DLEP to start the draft. - Tom From teco@inf-net.nl Thu Mar 29 03:47:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15F721F847E for ; Thu, 29 Mar 2012 03:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgl0hH6SVeAH for ; Thu, 29 Mar 2012 03:47:28 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8264621F847C for ; Thu, 29 Mar 2012 03:47:28 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1083886eaa.31 for ; Thu, 29 Mar 2012 03:47:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer:x-gm-message-state; bh=dG4PEwn5lHMjyuF99vpkK9uZMSQCgZXNCR+L0mSyO94=; b=gRRuS3linx49t4oMRxu2LrmxTrvwvr6TcqQj6MbEauVi4xga9lqWb0PMXd/b0eFmPn 6GrDZApZb1wq5M9M6LNvP9rtPPmcUlfhPmfcTZi2H3zqYyILWVewbUv/wB3znsFSJPhf dN2eGpJReXbqsPGu374M/z+kPM+hW5SEIXal97JuSu+j3AR7XZRtGMMbopM5SO2zYbSQ LZpnccmK9KLmHmSLmbRvEFfxZSqaWxQKd0dv2BE4Gov43VlZEwzO5BxRveIybArc2+Bv vLT6stjkd7OEZCnqPLr6+mmLPEnB0Z87yZSCCM69CCzUnLmtOSRaEKwxjb2dzIKjbt+B k9pg== Received: by 10.14.49.11 with SMTP id w11mr4749335eeb.40.1333018044277; Thu, 29 Mar 2012 03:47:24 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id z47sm20008095een.5.2012.03.29.03.47.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 03:47:22 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 Mar 2012 12:47:24 +0200 Message-Id: <978CA0E2-D3E4-4006-A83C-D11B9EDD68FF@inf-net.nl> To: Stan Ratliff Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlljNaXvnAztuGr7RfkLRZoytWHGS59WcpsyX+xhTEQ+/bquP/J61PYiX9EdJ2iefQN8P1Q Cc: "manet@ietf.org IETF" Subject: [manet] Comments on DLEP-02: semantics for direction X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:47:29 -0000 Hi Stan, I asked earlier for clarification of provided link characteristics. It looks to me some info is for the Tx direction (e.g. CDR, EFT) or Rx direction (e.g. RLQ). Or maybe for both directions. Could you make this more clearly defined? Thanks, Teco From hrogge@googlemail.com Thu Mar 29 03:54:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECC321F88E6 for ; Thu, 29 Mar 2012 03:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul+Sg4Q2d1el for ; Thu, 29 Mar 2012 03:54:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 711B721F87D2 for ; Thu, 29 Mar 2012 03:54:39 -0700 (PDT) Received: by lagj5 with SMTP id j5so2759882lag.31 for ; Thu, 29 Mar 2012 03:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wvQScxpAJKTq/UvH2AQ4HiFAk6KsP7Sb6x2LfpEIPrg=; b=QmuyHXneyzGWd8KCNdywP7IiFOa0h9A6ONhGCNVhFLfj5rEJZ/g0UBaPFOmPDIyQ5X 7xSqCVx5NuRlJb/qU0pf6S9m9mirR/HQ4repLMueBHMyoDclO037qPOVogvESx12CmuY uUXIqpI8UX0E6tsnpTM6Ya+a78HA4ZKbU/SXoLZ0QKkcDI41/HJqeCO08H0HOigqJIqa o4Gli1orP/d0ttPuJmb+rk7CeqwbFeY2T+QkiwUX4bVosRJjYGnHXwseaAuCXA50mTVj 8AjZilo1t53hee4QoEJviHhVAxqikaWDiChfIvkK0moDiw/YAIl23os+WyaUqewa/lV/ HquA== Received: by 10.152.123.229 with SMTP id md5mr27120662lab.34.1333018478374; Thu, 29 Mar 2012 03:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 29 Mar 2012 03:54:18 -0700 (PDT) In-Reply-To: <978CA0E2-D3E4-4006-A83C-D11B9EDD68FF@inf-net.nl> References: <978CA0E2-D3E4-4006-A83C-D11B9EDD68FF@inf-net.nl> From: Henning Rogge Date: Thu, 29 Mar 2012 13:54:18 +0300 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org IETF" , Stan Ratliff Subject: Re: [manet] Comments on DLEP-02: semantics for direction X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:54:49 -0000 I think the data we can get from the Mac80211 Linux implementation contains quite a few interesting and generic attributes that could be included into DLEP TLVs. Henning Rogge On Thu, Mar 29, 2012 at 13:47, Teco Boot wrote: > Hi Stan, > > I asked earlier for clarification of provided link characteristics. > It looks to me some info is for the Tx direction (e.g. CDR, EFT) > or Rx direction (e.g. RLQ). Or maybe for both directions. Could > you make this more clearly defined? > > Thanks, Teco > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Thu Mar 29 06:37:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D121F88D7 for ; Thu, 29 Mar 2012 06:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EooGFhZUZ1b3 for ; Thu, 29 Mar 2012 06:37:42 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 485B921F88AC for ; Thu, 29 Mar 2012 06:37:42 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so124465wgb.1 for ; Thu, 29 Mar 2012 06:37:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=JpzCcnLdh9RJNqFkrB5xn6Zdvpvmxlu4Wu1JtkeEW0A=; b=QDX2tU3shR3UJ0D2wjx/Pg8WLycXpp5gG6bIXXuGnU01374T6/Tuk75E/yoPaeHnTL sUlvWq3sk+lAeViHoUk5SIP/kr8Mt0KmdN9XCNCTaGmSe5rKuM4CAPFhhnDvVWfEupQM D8GDtOp10ipZVw16q0ak0Q2wlqgBNwyiY1vT8PZT1o2FEf9YsCNS8FyHR5tUt6uEhfni KsmpKAqm16GLNQOcUpLog+1yS9R/uqo4x4gp7nlkw+Nl12lIl2otrqecDcWnCtJB6wjR Uoo9aLCz1kV1eF7eW4fayTi4ytFaLSC906TLIBShCTiVWITvy8jiYClEAtstGaqNfMgO Nv6w== Received: by 10.180.105.194 with SMTP id go2mr5684595wib.22.1333028261491; Thu, 29 Mar 2012 06:37:41 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id 9sm28950750wid.2.2012.03.29.06.37.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 06:37:40 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 Mar 2012 15:37:37 +0200 Message-Id: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> To: "manet@ietf.org IETF" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlU03ZIASi9axPo9H6E3COe+ghBwKFWaP7pkL5yS2B4s+xdRdJfspRAO/Bio5DijHIb80SZ Subject: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:37:43 -0000 For the record, I repeat a remark I made on the mic. It looks to me LOADnd is targetted for the LLN use case and IETF has a wonderful WG for this. It is not MANET. Teco From ulrich@herberg.name Thu Mar 29 06:42:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57A421F853B for ; Thu, 29 Mar 2012 06:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCI6bjL11wpR for ; Thu, 29 Mar 2012 06:42:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAE21F86CE for ; Thu, 29 Mar 2012 06:42:29 -0700 (PDT) Received: by yenm5 with SMTP id m5so1589110yen.31 for ; Thu, 29 Mar 2012 06:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NKJ7YndSciBf4oxsK0Jl8bfDHVSWO0wFDENS/Xa8hOc=; b=mpWi8od5zbRtcHvNXjVjz6TKzW02bu2rvHN1Efs2w1VjMOM8IKyaEb72lyT0cSwtl6 xzF+QZiV1VsiRdorFk86emNGlDxy7XHgJij7Iz5WHI0dlERvFDxTz1lLRd1Un0Qj/eUJ MJDgbJOpwjdbAhoeqOxupsSgz4XkrQuymq7Sw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=NKJ7YndSciBf4oxsK0Jl8bfDHVSWO0wFDENS/Xa8hOc=; b=d6aIoSLgxIzl+zssD/2BYutUu7+RK6H8fuc86EdTvbF5UMwt93+tmYzJiuni1CFZ9c 6Z4xzyrwN3ck17Q5U0O9eqRnGd9Jwgkjt73mf7JhuHvickpbasU9JjVOuhO2PuguSifS 4HC4Nx8vagvjpqdN+NdfrhJrVeHohmOhq+dDBdAq2n+O4kup4HgKQIK5ksw938qP2wNn XaoRdnSzFO6jM6LExbupFc4bGwkjTK6ecrXuVRshjPLAbDrYMe7Dx+P+L/q73UzCKkZ8 SP8fPAJ2Ruu/0uyaGjTOJIuQQdLVqAFkz1/Q3eCfeo2XKYy1ItBnmlc8iwbC/E+iFyVU MZrA== MIME-Version: 1.0 Received: by 10.68.220.137 with SMTP id pw9mr84953pbc.122.1333028549093; Thu, 29 Mar 2012 06:42:29 -0700 (PDT) Received: by 10.143.29.18 with HTTP; Thu, 29 Mar 2012 06:42:29 -0700 (PDT) In-Reply-To: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> References: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> Date: Thu, 29 Mar 2012 15:42:29 +0200 Message-ID: From: Ulrich Herberg To: Teco Boot X-Gm-Message-State: ALoCoQlkTUSgK2D7Bz/myWV2y7aN15fCcnm8G3YDiKkRcjoa39PvqUXoQrgx5s+PPdDN2szjjNqh Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:42:32 -0000 Since this thread may start some discussion, I would like to point out the URL of the LOADng draft: http://tools.ietf.org/html/draft-clausen-lln-loadng Best regards Ulrich On Thu, Mar 29, 2012 at 3:37 PM, Teco Boot wrote: > > For the record, I repeat a remark I made on the mic. > It looks to me LOADnd is targetted for the LLN use case > and IETF has a wonderful WG for this. It is not MANET. > > Teco > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Mar 29 06:47:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2401B21F8A2E for ; Thu, 29 Mar 2012 06:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TRsZRMlVVmZ for ; Thu, 29 Mar 2012 06:47:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20721F8A2A for ; Thu, 29 Mar 2012 06:47:47 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1127476wgb.13 for ; Thu, 29 Mar 2012 06:47:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to:x-mailer:x-gm-message-state:content-type :content-transfer-encoding; bh=K7d4j57+SVeQN4K6g+zd4Y6xgfQEqPirBM3ykrG5Ufo=; b=ntQ+N7SvgZ32RqmfanDC0/yyIHAH+UORUH9JjmOJtI/yqQQYEuh3+eUsCxSz1/vq/G 79DjGAd7b5AOX5mgEHtG+Bl3E6uVXrWfG5jvdUOeVSoknQHB5hWcUGRAwZJiT0/qJgR2 +BdspkTV/mNFDbO0qu+JxpujTvC7ucrmMYbkHMP6wit9LgHlY1G5yX2Eig5BIfp51H3M yiqUFxKBB89llPaPySpxYf5r5iIofSYzbmUB369QKoiNYiFhH4OzvkbCZAYUw67p+XlX qNC4QW2fHJqUDNEpsRQwzQ1QdVI2bWWyRX7dzruzgBuZuU7ApjJjwzIK9G1i44YJa3zO O1tA== Received: by 10.180.103.134 with SMTP id fw6mr6749421wib.0.1333028865751; Thu, 29 Mar 2012 06:47:45 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id ex2sm28987465wib.8.2012.03.29.06.47.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 06:47:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) From: Teco Boot In-Reply-To: Date: Thu, 29 Mar 2012 15:47:41 +0200 Message-Id: <26030B62-C236-45BC-BBA4-0E298029FC0D@inf-net.nl> References: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> To: Ulrich Herberg X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl6hIxQPhFhYRNdDf9ZOkUDflzRX08TNUL1DRCrIMEzbeMvNEna+tPHGyxXpsxUEpuTomod Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:47:48 -0000 Is this discussed in ROLL? Teco Op 29 mrt. 2012, om 15:42 heeft Ulrich Herberg het volgende geschreven: > Since this thread may start some discussion, I would like to point out > the URL of the LOADng draft: > > http://tools.ietf.org/html/draft-clausen-lln-loadng > > Best regards > Ulrich > > On Thu, Mar 29, 2012 at 3:37 PM, Teco Boot wrote: >> >> For the record, I repeat a remark I made on the mic. >> It looks to me LOADnd is targetted for the LLN use case >> and IETF has a wonderful WG for this. It is not MANET. >> >> Teco >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From emmanuel.baccelli@gmail.com Thu Mar 29 07:00:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773F121F8AEA for ; Thu, 29 Mar 2012 07:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzxXn2fvnJHy for ; Thu, 29 Mar 2012 07:00:01 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 864D021F8A1B for ; Thu, 29 Mar 2012 07:00:01 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1597567qcs.31 for ; Thu, 29 Mar 2012 07:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=vomHMo4lmpBg4Tz3H7JcMqA7TmbOAHuVU6gKOvFp7og=; b=fU4gm4OrqdppjGdPcBbcycia7bUAzf7r5kukqMqHnGsc4snxZFnn0MUh/af+F26tA+ ELUzoZ9PDHLm0uYD18FX2C1xh9BdZebS923Xl/UwXJ8mFBuvbxcuJcBi3uTwopN2ZVkD fTfsM9IAUtInyUMJCpUgU5nkryfsAk6a7tTpxctsOwwsuzCPdkX8TB3y1bgs6XtmVGo9 jIuQ2ZycKY5dJwgCZv5SEjS+Kgv+8i977whQIFJIbgLyOGXESbnxyqngU/NCwtqeYPfV cejA5NpKRwqGMrW9le72gmscu+KsOXe0pCtEhfcnlLUX9eOKZHrHJjgGGkl0a1FhY/kB DE2w== Received: by 10.224.202.193 with SMTP id ff1mr287291qab.36.1333029600539; Thu, 29 Mar 2012 07:00:00 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.40.134 with HTTP; Thu, 29 Mar 2012 06:59:40 -0700 (PDT) In-Reply-To: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Thu, 29 Mar 2012 15:59:40 +0200 X-Google-Sender-Auth: edlEYHIaS9rO3vwsZUo3ZEO7Ogo Message-ID: To: "manet@ietf.org IETF" Content-Type: multipart/alternative; boundary=20cf300faff5d0b3c204bc62230f Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:00:02 -0000 --20cf300faff5d0b3c204bc62230f Content-Type: text/plain; charset=ISO-8859-1 Hi Teco, that is a good question. Actually, as far as I can see, LOADng mainly derives from AODV, and so does AODVv2, obviously. Maybe there is a way to simply "reconcile" the two approaches and have just one protocol (as I tried to express on the mic today). At first sight the main difference between the two approaches is probably the use of packetBB, so far mandatory in MANET. Hence my question about the advantages of NOT using packetBB: I suppose it has to do with the size of packets being bigger, and maybe more difficult to fit into small frames such as radio frames used in some LLNs, indeed? Emmanuel On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: > For the record, I repeat a remark I made on the mic. > It looks to me LOADnd is targetted for the LLN use case > and IETF has a wonderful WG for this. It is not MANET. > > Teco > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf300faff5d0b3c204bc62230f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,

that is a good question. Actually, as far as I can see, LOADng= mainly derives from AODV, and so does AODVv2, obviously.

Maybe t= here is a way to simply "reconcile" the two approaches and have j= ust one protocol (as I tried to express on the mic today).

At first sight the main difference between the two approaches is proba= bly the use of packetBB, so far mandatory in MANET.

Hence my ques= tion about the advantages of NOT using packetBB:=A0I suppose it has to do w= ith the size of packets being bigger, and maybe more difficult to fit into = small frames such as radio frames used in some LLNs, indeed?

Emmanuel

On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <= teco@inf-net.nl>= ; wrote:

For the record, I repeat a remark = I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

Teco
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf300faff5d0b3c204bc62230f-- From iesg-secretary@ietf.org Thu Mar 29 07:10:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7096121E811B; Thu, 29 Mar 2012 07:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKj99jA3hqeL; Thu, 29 Mar 2012 07:10:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B7021E80FE; Thu, 29 Mar 2012 07:10:49 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120329141049.23063.75773.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 07:10:49 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (Definition of Managed Objects for the Neighborhood Discovery Protocol) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:10:50 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Definition of Managed Objects for the Neighborhood Discovery Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-16. The span of this last call has been extended to account for the IETF meeting. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From charliep@computer.org Thu Mar 29 07:31:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD07021E81B3 for ; Thu, 29 Mar 2012 07:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHNoeZId53R0 for ; Thu, 29 Mar 2012 07:31:02 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7559D21E81AF for ; Thu, 29 Mar 2012 07:31:02 -0700 (PDT) Received: from [130.129.83.71] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SDGNP-0004xZ-9q for manet@ietf.org; Thu, 29 Mar 2012 10:30:59 -0400 Message-ID: <4F74722A.6060703@computer.org> Date: Thu, 29 Mar 2012 07:31:06 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Manet" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866a49cfaf4b0a7edaae07b21bf67774a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.71 Subject: [manet] A view on packet-BB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:31:03 -0000 Hello folks, I have not participated very much in any discussions about packet-BB other than to encourage header size reduction and offer a few suggestions about how to achieve it. During that time, it was claimed that for many networks of interest, the use of packet-BB would *decrease* header size, perhaps especially for proactive protocols. This is a question very suitable for resolution by way of simulation. If, as I suspect, packet-BB does (on average) introduce header enlargement on some networks that cannot afford it, I would be in favor to introduce the option to run AODV (or OLSR, for that matter) with some sort of "reduced" header. This should only be deployed in networks where otherwise there would be no feasible deployment of an ad-hoc networking protocol. From that perspective, it's almost a no brainer -- either deploy the standard stripped- down version, or deploy something else nonstandard that looks exactly like the stripped-down version. In summary, if there are cases where the [manet] protocols can only be deployed without packet-BB header overhead, then I think we should provide a solution for those cases. To be clear, I am happy either way, whether or not packet-BB headers are mandates in all cases. Also, to be clear, we can standardize AODVv2 *with* packet-BB right now, and submit for consideration another document for AODVv2 that does not require packet-BB. Or, we can enable both ways in the next revision. Or, we can standardize AODVv2 that does NOT use packet-BB, and then submit for consideration another document that DOES use packet-BB. All cases are just fine with me, depending on what the working group wants. Regards, Charlie P. From teco@inf-net.nl Thu Mar 29 07:36:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32AD21F87E1 for ; Thu, 29 Mar 2012 07:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg0DcJlCK7ga for ; Thu, 29 Mar 2012 07:36:29 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0121F86A7 for ; Thu, 29 Mar 2012 07:36:29 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so170597wgb.1 for ; Thu, 29 Mar 2012 07:36:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to:x-mailer:x-gm-message-state:content-type; bh=IpTY+7PcrZYomw0Cp+IhSfZwIis+moGMu49m5EJDgWI=; b=ISJ++C7YEF/lGSYMuF2TVy1PzAZzEK8oxtuKqsx3zc4E+RKypPRJsIYwbHPn/6oWNh zWnnZKjjTJW8d2XaVrB5Kg4jdmzXuiAk7Zg+q20avvVEMuUyf5338BJZ/TfA69OYoVGR 8KXcf9gJJPPZiWifuhgNNlJGMZUbbbiTKG5uhhb7eG7dOS3eCmvtsR+4KudrfuhYOtQr sUuKQnO2JwsyEaZKcmxdwt6Tok12NIDW+yKA8i5x9zoLHH2FAszz1OeL7yaQ6cFNtrPF ruE90fJYCjUve8/SN30EqFdGzxvn1IaSITAPGBaUqciqBoll2ErjTDpt+3JrWSVAblQb nMXA== Received: by 10.180.96.228 with SMTP id dv4mr6226751wib.14.1333031788647; Thu, 29 Mar 2012 07:36:28 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id n15sm67507490wiw.6.2012.03.29.07.36.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 07:36:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) From: Teco Boot In-Reply-To: Date: Thu, 29 Mar 2012 16:36:24 +0200 Message-Id: <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmsQPvI7O/XrwP2FH6+1TUsSN+/85TuIXmppmhaOAf5EQOYg/ysmakGpM1npL1MlBGOW14v Content-Type: multipart/alternative; boundary="Apple-Mail=_6ACDDCB6-3418-4F0E-AD89-34D07FE5211B" Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:36:30 -0000 --Apple-Mail=_6ACDDCB6-3418-4F0E-AD89-34D07FE5211B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I saw someone presenting a reactive p2p routing protocol in ROLL. I was = not aware of a suggestion on using packetBB. If you think it is useful, = you could post it over there. Teco Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: > Hi Teco, > that is a good question. Actually, as far as I can see, LOADng mainly = derives from AODV, and so does AODVv2, obviously. > Maybe there is a way to simply "reconcile" the two approaches and have = just one protocol (as I tried to express on the mic today). > At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. > Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? > Emmanuel >=20 >=20 >=20 > On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: > For the record, I repeat a remark I made on the mic. > It looks to me LOADnd is targetted for the LLN use case > and IETF has a wonderful WG for this. It is not MANET. >=20 > Teco > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_6ACDDCB6-3418-4F0E-AD89-34D07FE5211B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I saw someone presenting a reactive p2p routing protocol in ROLL. I was not aware of a suggestion on using packetBB. If you think it is useful, you could post it over there.

Teco

Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende geschreven:

Hi Teco,
that is a good question. Actually, as far as I can see, LOADng mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and have just one protocol (as I tried to express on the mic today).

At first sight the main difference between the two approaches is probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using packetBB: I suppose it has to do with the size of packets being bigger, and maybe more difficult to fit into small frames such as radio frames used in some LLNs, indeed?

Emmanuel

On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <teco@inf-net.nl> wrote:

For the record, I repeat a remark I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

Teco
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--Apple-Mail=_6ACDDCB6-3418-4F0E-AD89-34D07FE5211B-- From emmanuel.baccelli@gmail.com Thu Mar 29 08:00:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB4221E81DC for ; Thu, 29 Mar 2012 08:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+YFLi+4HD4t for ; Thu, 29 Mar 2012 08:00:47 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1821E81D5 for ; Thu, 29 Mar 2012 08:00:44 -0700 (PDT) Received: by qafi31 with SMTP id i31so484345qaf.15 for ; Thu, 29 Mar 2012 08:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=gzsZjWbNDHJs1k8fhYOBukwGBWPCA16NoTKAe6zA8Po=; b=pqsZCSLMEFD+GaejvWJNiHPvcbJTnonHklO9R+EHRs1qPwMXQEbCaca2MMnibFBDw/ npOqmJrUjx6qHj1YqYm7GQa3xDkaAjL/qIADU6kifmiOm/VZF3YoZCVQHuXuWlqabvSx 2MV/Y/UKzSHyxuqz1xEJc13AEp3EBdeq5ryPYecnzHr0dBCJ98xkiv/9+LgK3mySx3Co MZKao9wtMQ71cazY2OCod9CffsYw6ZB5WwjMODSyKi3C0WsLeyJr87NEp1cAT81BV3Pr nySuxDgeAjDR8etkSrCPNHdJTGMvdiSKloLVkhV5+iTAEo0fWzBCGr5cJKgrpgvtv+gl NcDA== Received: by 10.229.106.196 with SMTP id y4mr5628852qco.44.1333033243493; Thu, 29 Mar 2012 08:00:43 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.40.134 with HTTP; Thu, 29 Mar 2012 08:00:23 -0700 (PDT) In-Reply-To: <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> From: Emmanuel Baccelli Date: Thu, 29 Mar 2012 17:00:23 +0200 X-Google-Sender-Auth: xWgI4Pt3gd7O6ymFUOSnVq4E2zE Message-ID: To: "manet@ietf.org IETF" Content-Type: multipart/alternative; boundary=0023544700c0f3c47c04bc62fc24 Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:00:49 -0000 --0023544700c0f3c47c04bc62fc24 Content-Type: text/plain; charset=ISO-8859-1 Hi Teco, maybe I was not clear enough in my previous email: there is no suggestion to use packetBB in any ROLL draft I am aware of. I meant that, so far, a MANET protocol (and thus AODVv2) is by default supposed to use packetBB, whereas other protocols may not have to use packet BB. Emmanuel On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: > I saw someone presenting a reactive p2p routing protocol in ROLL. I was > not aware of a suggestion on using packetBB. If you think it is useful, you > could post it over there. > > Teco > > > Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende geschreven: > > Hi Teco, > that is a good question. Actually, as far as I can see, LOADng mainly > derives from AODV, and so does AODVv2, obviously. > Maybe there is a way to simply "reconcile" the two approaches and have > just one protocol (as I tried to express on the mic today). > At first sight the main difference between the two approaches is probably > the use of packetBB, so far mandatory in MANET. > Hence my question about the advantages of NOT using packetBB: I suppose it > has to do with the size of packets being bigger, and maybe more difficult > to fit into small frames such as radio frames used in some LLNs, indeed? > Emmanuel > > > > On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: > >> For the record, I repeat a remark I made on the mic. >> It looks to me LOADnd is targetted for the LLN use case >> and IETF has a wonderful WG for this. It is not MANET. >> >> Teco >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --0023544700c0f3c47c04bc62fc24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,

maybe I was not clear enough in my previous email: there is no= suggestion to use packetBB in any ROLL draft I am aware of.

I me= ant that, so far, a MANET protocol (and thus AODVv2) is by default supposed= to use packetBB, whereas other protocols may not have to use packet BB.

Emmanuel

On Thu, Mar 29, = 2012 at 4:36 PM, Teco Boot <teco@inf-net.nl> wrote:

I saw someone present= ing a reactive p2p routing protocol in ROLL. I was not aware of a suggestio= n on using packetBB. If you think it is useful, you could post it over ther= e.

Teco

Op 29 mrt. 201= 2, om 15:59 heeft Emmanuel Baccelli het volgende geschreven:

Hi Teco,
that is a good que= stion. Actually, as far as I can see, LOADng mainly derives from AODV, and = so does AODVv2, obviously.
Maybe there is a way to simply "r= econcile" the two approaches and have just one protocol (as I tried to= express on the mic today).

At first sight the main difference between the two approaches is proba= bly the use of packetBB, so far mandatory in MANET.
Hence my ques= tion about the advantages of NOT using packetBB:=A0I suppose it has to do w= ith the size of packets being bigger, and maybe more difficult to fit into = small frames such as radio frames used in some LLNs, indeed?

Emmanuel

On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <= teco@inf-net.nl>= ; wrote:

For the record, I repeat a remark = I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

Teco
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
http= s://www.ietf.org/mailman/listinfo/manet

____________= ___________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--0023544700c0f3c47c04bc62fc24-- From teco@inf-net.nl Thu Mar 29 08:17:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA15021E81EE for ; Thu, 29 Mar 2012 08:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDGreKfjuZKk for ; Thu, 29 Mar 2012 08:17:00 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8ABA21E81ED for ; Thu, 29 Mar 2012 08:16:59 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so130632wib.13 for ; Thu, 29 Mar 2012 08:16:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=vy8Rb523WlQrbznroSc+OSCTTgByT8GqMMcxMOh4e2w=; b=aKVTWMMUlMsGarNFXhZQjrw5sNNV6je0Pj4gCBTEpx0BpVsiPgFEU9GZWmCXGG+e+F EweqxkLCFPStjz1d4QiXbNi12Bvo4t7OPuHmAX3mVbEjq/01+XVFwGyHTttVnqMU8sFR 5bCFA+S28mN38Qfbx/o507g/wdN1rq8/I4THh1m6W9/pR+h3JOWJDeACity/Y8FoA+Yl 0aiJUlDbWnJm68WHBtUb7h3fShaAdohxDgGRh/TlGpKdvoZoUqrLcDO6OdOH6qN+deW/ vFv0CIzGfEFMQNI0LtnChNbXZFpX7jPrts0xmcX6SGWE9npQnF3fIWF8fWeZRav+l7cL 6FPw== Received: by 10.180.95.34 with SMTP id dh2mr6563931wib.15.1333034218884; Thu, 29 Mar 2012 08:16:58 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id fn2sm29934445wib.0.2012.03.29.08.16.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:16:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_020B1D69-B173-4A13-B4AF-D6A6AD974BC5" From: Teco Boot In-Reply-To: Date: Thu, 29 Mar 2012 17:16:54 +0200 Message-Id:

= --_000_F9FF1B7208614B778043F25497138D68nasagov_-- From teco@inf-net.nl Fri Mar 30 11:50:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742B121F8621 for ; Fri, 30 Mar 2012 11:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+DRrEIlQnE2 for ; Fri, 30 Mar 2012 11:50:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A16E321F861A for ; Fri, 30 Mar 2012 11:50:10 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so583876wgb.13 for ; Fri, 30 Mar 2012 11:50:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version:x-mailer :x-gm-message-state:content-type:content-transfer-encoding; bh=ZcQ4/DQElksfHjOkaYCNSLdM6vm8wWP32BomQt4cTS8=; b=C8irOuFLzQdhcrGFoa1NsfapKc5xJTjPxnhXEnjfZnqiIx5LJIYtoReFTB/zdUF06m Y4nFdIn+rrZ0KtNb8MJuyZvhOxfokeo4SbdRtZ20DLn17UCLh8KtsUB9jVyPB4KOR356 NL5LjDMu5gprPLznhEDZOqa78sPeNurtR6aVUbASMEs1oYebl4oKQ1WmPtMhXCoS9rNv L3AybaORccyNcqXP1hYQUQOCTuoSH/2DgVagrKu13gDq2oA41vGfTqBKtYwxnOhTyFnO xfvrVTTaaZELv6YK98coxh4lbzoMU/URc3mDaMhx0nxQWrBljUki2GywddPmz6VNZD2G 0TtA== Received: by 10.180.24.66 with SMTP id s2mr816946wif.7.1333133409810; Fri, 30 Mar 2012 11:50:09 -0700 (PDT) Received: from [10.87.37.11] ([80.187.201.33]) by mx.google.com with ESMTPS id j3sm13697867wiw.1.2012.03.30.11.50.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 11:50:09 -0700 (PDT) From: Teco Boot Date: Fri, 30 Mar 2012 17:38:22 +0200 Message-Id: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> To: "Stan Ratliff (sratliff)" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkLg1y8UUbEHUPHC+IPD9JA+oM4T7LroAf4uxHm4LL450EGqglkn2/nX1qcH86UkLcxCyXu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "manet@ietf.org IETF" Subject: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks

Since manets are targeted = for first responders and the military and other edge networks, anything = overly complex is not practical to = deploy.

But some are playing with = it. Or struggling :-)

.... and we = haven't event touched upon security requirements in a military = setting.

I guess we (IETF) won't touch = security for military...

Now I put money on my = horse.

Teco

Why = would we like " for more intelligent waveforms to handle the routing = internally" ?

Thanks, Bob

----- Original Message = -----
From: Powell lll, Nelson [mailto:npowell@harris.com]
Sent: = Friday, March 30, 2012 01:32 PM
To: Rick Taylor <Rick.Taylor@Cassidian.com>= ;; manet@ietf.org <manet@ietf.org>
Cc: sratliff@cisco.com <sratliff@cisco.com>
Subject: = Re: [manet] DLEP and multi-hop neighbours

Rick,
I'm not sure = it is a "problem" so much as it is a feature. Allowing a radio to behave = as a "neighbor" allows for more intelligent waveforms to handle the = routing internally. If a hop-count were added, I would imagine that = should be more an optional TLV, as intelligent waveforms may use latency = in a similar manner.

Nelson

-----Original = Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor
Sent: = Friday, March 30, 2012 6:35 AM
To: manet@ietf.org
Cc: sratliff@cisco.com
Subject: = [manet] DLEP and multi-hop neighbours

As part of our on-going = work with DLEP, we have discovered a problem
with the definition of a = neighbour on a DLEP session.

In a smart meshing radio network, = each DLEP radio could report all its
multi-hop link-neighbours as = DLEP neighbours. This is valid according
to the wording of = draft-02, but is misleading to any router attempting
to discover the = topology of the actual radio network.

A proposed resolution to = this problem is rather than force only 1-hop
neighbours to be = reported via DLEP, add an extra 'hop-count' TLV to the
NeighbourUp = message. Of course adding an extra TLV just for a single
octet = seems like a lot of extra data, perhaps the RFC5444 gurus can
suggest = a more elegant method? Or perhaps the absence of the hop-count
TLV = implies a 1-hop neighbour?

Rick = Taylor
_______________________________________________
manet = mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet
____________________________________________= ___
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
_= ______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= /div>

William D. Ivancic
Fax 216-433-8705
Networking Lab 216-433-2620
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_81D1E702-84C1-4461-9893-7341A29A7061-- From sdas@appcomsci.com Fri Mar 30 13:29:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE3D21F85D9 for ; Fri, 30 Mar 2012 13:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okiypq3zSpyC for ; Fri, 30 Mar 2012 13:29:52 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id B287421F85D7 for ; Fri, 30 Mar 2012 13:29:52 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q2UKTj5Z027656; Fri, 30 Mar 2012 16:29:45 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q2UKTh6R023735; Fri, 30 Mar 2012 16:29:43 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 16:29:46 -0400 From: "Das, Subir" To: "Cole, Robert G CIV USARMY CERDEC (US)" Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0OYMBxlxUrjbJdSvCFQoX4+0t8iQAF+OOAAAeJOiYAB0PdBw== Date: Fri, 30 Mar 2012 20:29:45 +0000 Message-ID: <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 30 Mar 2012 15:07:13 -0700 Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:29:53 -0000 I have the same question. I assume we are consideri L3 routing here not=20 Sent from my iPhone On Mar 30, 2012, at 1:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: > Why would we like " for more intelligent waveforms to handle the routing = internally" ? >=20 > Thanks, Bob >=20 > ----- Original Message ----- > From: Powell lll, Nelson [mailto:npowell@harris.com] > Sent: Friday, March 30, 2012 01:32 PM > To: Rick Taylor ; manet@ietf.org > Cc: sratliff@cisco.com > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > Rick, > I'm not sure it is a "problem" so much as it is a feature. Allowing a rad= io to behave as a "neighbor" allows for more intelligent waveforms to handl= e the routing internally. If a hop-count were added, I would imagine that s= hould be more an optional TLV, as intelligent waveforms may use latency in = a similar manner. >=20 > Nelson >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Rick Taylor > Sent: Friday, March 30, 2012 6:35 AM > To: manet@ietf.org > Cc: sratliff@cisco.com > Subject: [manet] DLEP and multi-hop neighbours >=20 > As part of our on-going work with DLEP, we have discovered a problem > with the definition of a neighbour on a DLEP session. >=20 > In a smart meshing radio network, each DLEP radio could report all its > multi-hop link-neighbours as DLEP neighbours. This is valid according > to the wording of draft-02, but is misleading to any router attempting > to discover the topology of the actual radio network. >=20 > A proposed resolution to this problem is rather than force only 1-hop > neighbours to be reported via DLEP, add an extra 'hop-count' TLV to the > NeighbourUp message. Of course adding an extra TLV just for a single > octet seems like a lot of extra data, perhaps the RFC5444 gurus can > suggest a more elegant method? Or perhaps the absence of the hop-count > TLV implies a 1-hop neighbour? >=20 > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sat Mar 31 00:47:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1021F84D6 for ; Sat, 31 Mar 2012 00:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkMVSnP3Edj8 for ; Sat, 31 Mar 2012 00:47:10 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A76821F847C for ; Sat, 31 Mar 2012 00:47:09 -0700 (PDT) Received: by lagj5 with SMTP id j5so1808900lag.31 for ; Sat, 31 Mar 2012 00:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KkE4EsiZd5su40YnlsG9NML/yoEXIyKEZGZrpvDlna4=; b=xZL3nO/52/d3IPkK5QMiCgVeNEwmlsFBhoVhDSbJoTZ4CL9psinMz6w1RPSH0R65k0 F6tWoT8Xg388H6UAx7x1rCE0JTY3KpiXXcHKRDD+8U6k71kTERwPMhLgxQEKTrkyyNSL BW76p1VP4ThU0C80HqUwApOUPxan5mjdA4CFTJGTeGC4nrqUDM2dxXVACvlLI8KtUaVb xUqA4YobFcVJxjk3ZHfi7E4/lnffZN3yanuXH/fJ6NquQg44r4prLJE0YT4TwTtGAHZY pTwC5Acet1hbWRgWu0Pd95tex8kT6mi41dG6jNsMYUaU3LEXX0TbR3BQ7StjA+kUf2pG UBUw== Received: by 10.152.103.239 with SMTP id fz15mr1498793lab.42.1333180029040; Sat, 31 Mar 2012 00:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sat, 31 Mar 2012 00:46:48 -0700 (PDT) In-Reply-To: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> From: Henning Rogge Date: Sat, 31 Mar 2012 10:46:48 +0300 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org IETF" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 07:47:11 -0000 On Fri, Mar 30, 2012 at 18:38, Teco Boot wrote: > Stan, > > Seen the discussion on hop-count and probably lots of other > nice to haves, an employee of a random router vender would > easily get crazy to get all of this in a useful metric for > the routing protocols. > > I suggest to define a new metric type, to be used by modems, > to provide a dimensionless value that is used directly in the > routing protocol. After a bit of discussion, we have a nice > outcome of a 12-bit compressed form of a link metric OLSRv2. > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 > > You may have a need for a 16-bit uncompressed dimensionless value > for OSPF. You could opt for a / 256 of the decompressed value > or go for another metric type. Important: OSPF needs the metric > for outgoing traffic, OLSR for incoming traffic (OLSR transfers > it to neighbor with hello). > > You could use the Neighbor Incoming / Outgoing Metric bits, you > have the 4-bit placeholder already. If Layer-2 data is available, it should be exported in "raw" format by the DLEP service/server. Especially data that cannot be easily calculated by the connected computer like "Throughput" (real one, not just hardware transmission speed), Transmission loss and transmission attempts. And for Radios we definitely need Frequency and Bandwidth (width of the radio channel in Hz). These two values are also interesting to use in the "request link characteristic" message to reconfigure a radio. > With MAC address-block TLVs, assuming a 6-byte MAC address with > first 3 bytes mostly being equivalent, the space per neighbor > would be 5 bytes. Not that bad. But to make use of this, you > may need to have repeatedly having send this info instead of > having a reliable transport inside DLEP. This needs validity > timers, so it is not a minor change. You mean space including your dimensionless metric TLV? Something different, is the addition of IPs to the DLEP messages really a common usecase? DLEP defines the radio to be a layer-2 bridge to the ethernet (most likely VLAN tagged to separate it from the control stream), so the radio/modem does not need any IP address except for some linklocal one on the control interface. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sat Mar 31 00:49:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6621F84EB for ; Sat, 31 Mar 2012 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnNakyoh4-LA for ; Sat, 31 Mar 2012 00:49:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C41CD21F84E2 for ; Sat, 31 Mar 2012 00:49:31 -0700 (PDT) Received: by lagj5 with SMTP id j5so1810314lag.31 for ; Sat, 31 Mar 2012 00:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pMgyAG9nY9afYGiIE/SKBWHcub4Wz3FtpcgBx8CIbLw=; b=e7zQiiiYdpU22LIlNkECIcwAdkG1RTTCxFC0hUGkHcCFwFC+bsD4cYNSsqFaO4JP5K Pxpk9arzH92Ipg+sQMlbn6cGqu8hQbPzQba+ty9xlz0lBHOCc1sfOOXFKIrKYwI8Vxl1 WrJbHdhWT8McJcFzI3SLmKLei3YmrWaWyeG2h+G/G9982eX3QXZtJSxfykxA4/2g2xfA dkEmq4MgINHRD7tZG+vrOpXN2U8XoXNgEdXXGxGPdUlP1Bbjs/XzNu9zQ0Bgu+dAdirw tKor5zO96LJP/kGHUF/az6uGyM0ZktyzqhBbKSetuiTxoitO6hWjFFkqGOb5YOnkCRos NPkQ== Received: by 10.152.123.229 with SMTP id md5mr1528086lab.34.1333180170809; Sat, 31 Mar 2012 00:49:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sat, 31 Mar 2012 00:49:10 -0700 (PDT) In-Reply-To: <64D06532-BCCE-49C8-B3AA-E424B830C04B@inf-net.nl> References:

<64D06532-BCCE-49C8-B3AA-E424B830C04B@inf-net.nl> From: Henning Rogge Date: Sat, 31 Mar 2012 10:49:10 +0300 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 07:49:32 -0000 On Fri, Mar 30, 2012 at 22:14, Teco Boot wrote: > > Op 30 mrt. 2012, om 19:31 heeft Ivancic, William D. (GRC-RHN0) het volgen= de > geschreven: > > My experience is that you want to either let the radios do routing at > layer-2 or routers do routing at layer-3. If you have a split, the two > systems will fight each other. > > +1 Yes. Having a layer 3 routing over a layer 2 mesh can be a nightmare. > Since manets are targeted for first responders and the military and other > edge networks, anything overly complex is not practical to deploy. > > +1 > But some are playing with it. Or struggling :-) > > =A0 .... and we haven't event touched upon security requirements in a mil= itary > setting. > > I guess we (IETF) won't touch security for military... > Now I put money on my horse. If DLEP only communicates between the radio and the (ethernet-) attached router, there is not much security necessary for this control path. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sat Mar 31 01:49:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBDE21F8675 for ; Sat, 31 Mar 2012 01:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxKhn5GdJg00 for ; Sat, 31 Mar 2012 01:49:21 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDFC21F8674 for ; Sat, 31 Mar 2012 01:49:21 -0700 (PDT) Received: by lagj5 with SMTP id j5so1845627lag.31 for ; Sat, 31 Mar 2012 01:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=WGNqmRjjsAYpyxsOSm8uU0D8PHzCAHatnLY8GSZT2QU=; b=HFHu/+Ni/+jobwOeqAs2RDOYCJmxcVeSBHnh2HBKe0UUHEn9vSlqCScBt8VMykou+W gsMhwlalhKtqJP+JwCcROBaMCPyaNRAf32oNKatKp9fLqjRtg8mqSJHpEcvAEZp22zXA IL4PmODA9HElRwfgnfw3n1myBtlmdI27bdwY3S4mX24FSzpK6TJctmdrC/R/+yOBQzMV JLwaiWI5JhaW8LVZUkzK09moleeJJQ4l5l2a6e1qaDRyRVgZS0kbEOpqBBlRPYj3OfSn jQnr6qizlh2UcxbEEXS3WvJ0dAWJGlttbplUJJD/4CJLMPQNBAhEFJHj6cnQKXD3KTUj wg0A== Received: by 10.152.129.137 with SMTP id nw9mr1627519lab.48.1333183760235; Sat, 31 Mar 2012 01:49:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sat, 31 Mar 2012 01:49:00 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC103566105@SUKNPT8106.cogent-dsn.local> References:

<56D06C32-9944-4522-B886-F5E765B9D2F5@gmail.com> <7B31B0093014224A843C10C0CCE92AC1035200DC@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103566105@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Sat, 31 Mar 2012 11:49:00 +0300 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, "Stan Ratliff \(sratliff\)" , Christopher Dearlove Subject: Re: [manet] DLEP and RFC 5444 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 08:49:22 -0000 On Fri, Mar 30, 2012 at 18:12, Rick Taylor wrot= e: > Teco, > > It's not that clear-cut. =A0The heartbeat messages between router and pee= r > (Peer*) messages are the most frequent, but are small. =A0The > NeighbourUpdate messages are the next most common (unless the net is > changing faster than the heartbeat interval) and they have a larger > payload (should be all the changed metrics, but the devices we are using > send all metrics every time). > > I can see your point about just multicasting Neighbour* messages, but > the Peer* messages are very useful when sent from router to radio, e.g. > LinkCharacteristics, or when the local radio wants to inform the peered > router of global metric changes, so I am against removing that local > association (and some want to use it for credit-windowing). The peer offer/ack can also be used to automatically detect and configure a radio plugged into the corresponding switch. It might be interesting to add a VLAN TLV to choose the VLAN Tag the radio is bridged to. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sdas@appcomsci.com Sat Mar 31 08:17:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D8921F849C for ; Sat, 31 Mar 2012 08:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxbprsBru72A for ; Sat, 31 Mar 2012 08:17:24 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4548D21F849B for ; Sat, 31 Mar 2012 08:17:24 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q2VFHMs3005514; Sat, 31 Mar 2012 11:17:22 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q2VFHMGi029597; Sat, 31 Mar 2012 11:17:22 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 11:17:24 -0400 From: "Das, Subir" To: "Das, Subir" , "Cole, Robert G CIV USARMY CERDEC (US)" Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0OYMBxlxUrjbJdSvCFQoX4+0t8iQAF+OOAAAeJOiYAB0PdBwAnLZKw Date: Sat, 31 Mar 2012 15:17:23 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net>, <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> In-Reply-To: <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 15:17:25 -0000 Sorry for my incomplete message..=20 I assume we are considering L3 routing not L2 routing.=20 -Subir=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= as, Subir Sent: Friday, March 30, 2012 4:30 PM To: Cole, Robert G CIV USARMY CERDEC (US) Cc: manet@ietf.org; sratliff@cisco.com Subject: Re: [manet] DLEP and multi-hop neighbours I have the same question. I assume we are consideri L3 routing here not=20 Sent from my iPhone On Mar 30, 2012, at 1:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: > Why would we like " for more intelligent waveforms to handle the routing = internally" ? >=20 > Thanks, Bob >=20 > ----- Original Message ----- > From: Powell lll, Nelson [mailto:npowell@harris.com] > Sent: Friday, March 30, 2012 01:32 PM > To: Rick Taylor ; manet@ietf.org=20 > > Cc: sratliff@cisco.com > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > Rick, > I'm not sure it is a "problem" so much as it is a feature. Allowing a rad= io to behave as a "neighbor" allows for more intelligent waveforms to handl= e the routing internally. If a hop-count were added, I would imagine that s= hould be more an optional TLV, as intelligent waveforms may use latency in = a similar manner. >=20 > Nelson >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf=20 > Of Rick Taylor > Sent: Friday, March 30, 2012 6:35 AM > To: manet@ietf.org > Cc: sratliff@cisco.com > Subject: [manet] DLEP and multi-hop neighbours >=20 > As part of our on-going work with DLEP, we have discovered a problem=20 > with the definition of a neighbour on a DLEP session. >=20 > In a smart meshing radio network, each DLEP radio could report all its=20 > multi-hop link-neighbours as DLEP neighbours. This is valid according=20 > to the wording of draft-02, but is misleading to any router attempting=20 > to discover the topology of the actual radio network. >=20 > A proposed resolution to this problem is rather than force only 1-hop=20 > neighbours to be reported via DLEP, add an extra 'hop-count' TLV to=20 > the NeighbourUp message. Of course adding an extra TLV just for a=20 > single octet seems like a lot of extra data, perhaps the RFC5444 gurus=20 > can suggest a more elegant method? Or perhaps the absence of the=20 > hop-count TLV implies a 1-hop neighbour? >=20 > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sat Mar 31 08:28:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A921F853E for ; Sat, 31 Mar 2012 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1LcI1nUNnK8 for ; Sat, 31 Mar 2012 08:28:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD121F852B for ; Sat, 31 Mar 2012 08:28:01 -0700 (PDT) Received: by lagj5 with SMTP id j5so2093431lag.31 for ; Sat, 31 Mar 2012 08:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=QK9GBp5kAbbvVgPRxRRutKqfM/+bG4EkauUz7tfbAbY=; b=LHiGtubrId23U+CLY6vXeUlHOuxS59EHjJB6O/O2KE+7USQWS47wnCqZZ2nMmlnG+q wZHsunIs1J6OX/AXgb/rQnetw3WtQJ3DxKQpeWH7R5k8M7D5DBwNkAp4jDf1VS7+rxnY XuDtkS+lLvw0avVHXVyTFEWnGEDMsnGqenbAq2q9QifI7PAlXPUUfCOiBqn2sNHEhXmp mpRMl8hD2YfHuB1HEoINInt7RbC9w9XmT/MEK+LdnN6wS5dP4rqn/2c5Johkmctrl0Id i9z1vLs1uO1L736n8Ph9atGgjW8OVNkium36Sj6aKikYJ18H5JroA3BaknpGF5KLq5GR kjtg== Received: by 10.152.127.9 with SMTP id nc9mr2701013lab.20.1333207680412; Sat, 31 Mar 2012 08:28:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sat, 31 Mar 2012 08:27:40 -0700 (PDT) In-Reply-To: References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net> <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> From: Henning Rogge Date: Sat, 31 Mar 2012 18:27:40 +0300 Message-ID: To: "Das, Subir" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 15:28:03 -0000 >From the draft: > DLEP assumes that participating clients appear to the server as a > transparent bridge - specifically, the assumption is that the > destination MAC address for data traffic in any frame emitted by > the server should be the MAC address of the next-hop router or end- > device, and not the MAC address of any of the intervening clients. If the "Server/Radio/Interface" is a layer 3 router, why should it need DLE= P? Henning Rogge On Sat, Mar 31, 2012 at 18:17, Das, Subir wrote: > Sorry for my incomplete message.. > > I assume we are considering L3 routing not L2 routing. > > -Subir > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Das, Subir > Sent: Friday, March 30, 2012 4:30 PM > To: Cole, Robert G CIV USARMY CERDEC (US) > Cc: manet@ietf.org; sratliff@cisco.com > Subject: Re: [manet] DLEP and multi-hop neighbours > > I have the same question. I assume we are consideri > L3 routing here not > > Sent from my iPhone > > On Mar 30, 2012, at 1:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: > >> Why would we like " for more intelligent waveforms to handle the routing= internally" ? >> >> Thanks, =A0Bob >> >> ----- Original Message ----- >> From: Powell lll, Nelson [mailto:npowell@harris.com] >> Sent: Friday, March 30, 2012 01:32 PM >> To: Rick Taylor ; manet@ietf.org >> >> Cc: sratliff@cisco.com >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> Rick, >> I'm not sure it is a "problem" so much as it is a feature. Allowing a ra= dio to behave as a "neighbor" allows for more intelligent waveforms to hand= le the routing internally. If a hop-count were added, I would imagine that = should be more an optional TLV, as intelligent waveforms may use latency in= a similar manner. >> >> Nelson >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Rick Taylor >> Sent: Friday, March 30, 2012 6:35 AM >> To: manet@ietf.org >> Cc: sratliff@cisco.com >> Subject: [manet] DLEP and multi-hop neighbours >> >> As part of our on-going work with DLEP, we have discovered a problem >> with the definition of a neighbour on a DLEP session. >> >> In a smart meshing radio network, each DLEP radio could report all its >> multi-hop link-neighbours as DLEP neighbours. =A0This is valid according >> to the wording of draft-02, but is misleading to any router attempting >> to discover the topology of the actual radio network. >> >> A proposed resolution to this problem is rather than force only 1-hop >> neighbours to be reported via DLEP, add an extra 'hop-count' TLV to >> the NeighbourUp message. =A0Of course adding an extra TLV just for a >> single octet seems like a lot of extra data, perhaps the RFC5444 gurus >> can suggest a more elegant method? Or perhaps the absence of the >> hop-count TLV implies a 1-hop neighbour? >> >> Rick Taylor >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sdas@appcomsci.com Sat Mar 31 08:59:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB5021F857D for ; Sat, 31 Mar 2012 08:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB2rFgltIrDt for ; Sat, 31 Mar 2012 08:59:29 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7E21F856D for ; Sat, 31 Mar 2012 08:59:29 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q2VFxRXg007410; Sat, 31 Mar 2012 11:59:27 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q2VFxRoB029818; Sat, 31 Mar 2012 11:59:27 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 11:59:29 -0400 From: "Das, Subir" To: "'Henning Rogge'" Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0OYMBxlxUrjbJdSvCFQoX4+0t8iQAF+OOAAAeJOiYAB0PdBwAnLZKwAAjx4gAAB/kDAA== Date: Sat, 31 Mar 2012 15:59:26 +0000 Message-ID: References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net> <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 15:59:30 -0000 I do not think that Radio or client interface is considered as a L3 router = but Server is.=20 Also draft says: "DLEP is independent of the underlying link type and topol= ogy."=20 _Subir=20 -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: Saturday, March 31, 2012 11:28 AM To: Das, Subir Cc: Cole, Robert G CIV USARMY CERDEC (US); manet@ietf.org; sratliff@cisco.c= om Subject: Re: [manet] DLEP and multi-hop neighbours >From the draft: > DLEP assumes that participating clients appear to the server as a=20 > transparent bridge - specifically, the assumption is that the=20 > destination MAC address for data traffic in any frame emitted by the=20 > server should be the MAC address of the next-hop router or end-=20 > device, and not the MAC address of any of the intervening clients. If the "Server/Radio/Interface" is a layer 3 router, why should it need DLE= P? Henning Rogge On Sat, Mar 31, 2012 at 18:17, Das, Subir wrote: > Sorry for my incomplete message.. > > I assume we are considering L3 routing not L2 routing. > > -Subir > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf=20 > Of Das, Subir > Sent: Friday, March 30, 2012 4:30 PM > To: Cole, Robert G CIV USARMY CERDEC (US) > Cc: manet@ietf.org; sratliff@cisco.com > Subject: Re: [manet] DLEP and multi-hop neighbours > > I have the same question. I assume we are consideri > L3 routing here not > > Sent from my iPhone > > On Mar 30, 2012, at 1:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: > >> Why would we like " for more intelligent waveforms to handle the routing= internally" ? >> >> Thanks, =A0Bob >> >> ----- Original Message ----- >> From: Powell lll, Nelson [mailto:npowell@harris.com] >> Sent: Friday, March 30, 2012 01:32 PM >> To: Rick Taylor ; manet@ietf.org=20 >> >> Cc: sratliff@cisco.com >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> Rick, >> I'm not sure it is a "problem" so much as it is a feature. Allowing a ra= dio to behave as a "neighbor" allows for more intelligent waveforms to hand= le the routing internally. If a hop-count were added, I would imagine that = should be more an optional TLV, as intelligent waveforms may use latency in= a similar manner. >> >> Nelson >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On=20 >> Behalf Of Rick Taylor >> Sent: Friday, March 30, 2012 6:35 AM >> To: manet@ietf.org >> Cc: sratliff@cisco.com >> Subject: [manet] DLEP and multi-hop neighbours >> >> As part of our on-going work with DLEP, we have discovered a problem=20 >> with the definition of a neighbour on a DLEP session. >> >> In a smart meshing radio network, each DLEP radio could report all=20 >> its multi-hop link-neighbours as DLEP neighbours. =A0This is valid=20 >> according to the wording of draft-02, but is misleading to any router=20 >> attempting to discover the topology of the actual radio network. >> >> A proposed resolution to this problem is rather than force only 1-hop=20 >> neighbours to be reported via DLEP, add an extra 'hop-count' TLV to=20 >> the NeighbourUp message. =A0Of course adding an extra TLV just for a=20 >> single octet seems like a lot of extra data, perhaps the RFC5444=20 >> gurus can suggest a more elegant method? Or perhaps the absence of=20 >> the hop-count TLV implies a 1-hop neighbour? >> >> Rick Taylor >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Steven Hawkings about cosmic inflation: "An increase of billions of billion= s of percent in a tiny fraction of a second. Of course, that was before the= present government."