[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-dlep-lid

Mobile Ad hoc Networks Working Group                           R. Taylor
Internet-Draft                                                J. Dowdell
Expires: January 1, 2015                          Airbus Defence & Space
                                                           June 30, 2014


                       Layer-3 Extensions to DLEP
                     draft-taylor-manet-l3-dlep-00

Abstract

   There exists a class of devices where DLEP functionality is desired
   but as the devices operate at layer-3, supporting the core DLEP
   specification with its requirement that modems operate as transparent
   layer-2 bridges is inappropriate.

   This document introduces two optional extensions to the core DLEP
   specification.  Each extension may be used in isolation without
   breaking backwards compatibility.

   By relaxing the requirement that all DLEP destinations be identified
   by MAC address, and the addition of a new extension TLV describing
   available destination routes, the functionality of DLEP can be
   implemented by layer-3 forwarding devices.

   Note:

   o  This document is intended as an extension to the core DLEP
      specification, and readers are expected to be fully conversant
      with the operation of core DLEP.

   o  The DLEP specification is still in draft, and this document serves
      a secondary purpose to explore and validate the extension
      mechanisms detailed in DLEP.  This document will therefore require
      further update as the core DLEP draft progresses towards standards
      track.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.





Taylor & Dowdell         Expires January 1, 2015                [Page 1]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 1, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Non MAC-Address Destination Identitifers  . . . . . . . . . .   3
     2.1.  Non MAC TLV . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Destination Identifiers In Exisiting Data Items . . . . .   4
   3.  External Route Advertisement  . . . . . . . . . . . . . . . .   5
     3.1.  Route TLV . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Registration  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Dynamic Link Exchange Protocol [DLEP] describes a protocol for
   modems to advertise the status of wireless links between reachable
   destinations to attached routers.  The core specification of the
   protocol assumes that the participating modems operate as a
   transparent bridge, and that destinations are identified by MAC
   address.

   There exists some classes of devices where this reachability model is
   too restrictive but the benefits of the DLEP protocol are desired,



Taylor & Dowdell         Expires January 1, 2015                [Page 2]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


   such as destination availability sensing, credit windowing, and/or
   link metrics.  Examples of such devices include modems with some
   advanced, possibly proprietary, routing capability implemented within
   the device; or modems with cryptographic capability, where the DLEP
   functionality is required on the clear-text side but the destinations
   are actually addressed on the cipher-text side via some tunnelling
   technology.

   To enable such devices to take advantage of the DLEP protocol this
   specification adds two extensions to the DLEP protocol: Non MAC-
   address destination identifiers and external route advertisement.
   Both extensions are marked as OPTIONAL in this document, meaning that
   either one, or the other, or both may be implemented by a conforming
   router or modem.

   A criticism of this extension could be that such layer-3 devices
   should instead be running one or more instances of a layer-3 routing
   protocol to exchange routes; in that case the core functionality of
   DLEP would have to be implemented in a seperate, but very similar,
   protocol.  This document attempts to avoid such a cloning of the DLEP
   core functionality by extending the DLEP specification with optional
   mechanisms to allow such layer-3 devices to operate.

1.1.  Requirements

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

2.  Non MAC-Address Destination Identitifers

   In the core DLEP specification it is stated that 'The MAC address TLV
   MUST appear in all destination-oriented signals'.  The extension
   described here replaces the semantics of the MAC address in the TLV
   with a unique Destination Identifier.

   The requirements of a destination identifier is that each destination
   MUST be unique within the DLEP session and not reused during the
   lifetime of a session.  Multicast or group destinations are not
   supported by this extension; such functionality should be implemented
   by using layer-3 multicast addresses.

   During DLEP Peer Initialization, a modem that wishes to advertise
   that it implements this extension MUST include the new Non MAC TLV
   that indicates that all destinations advertised by the device are not
   MAC addresses and therefore not addressable at layer-2.  Each




Taylor & Dowdell         Expires January 1, 2015                [Page 3]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


   destination identifier MUST have the length of the number of octets
   specified in the Non MAC TLV presented during session initialization

   By supporting this extension, the modem indicates that any peer
   router at a destination is not addressable via the destination
   identifier presented in any of the destination orientated signals
   (e.g.  Destination Update), and therefore MUST include at least one
   IPv4 or IPv6 Address TLV in the Destination Up signal.

2.1.  Non MAC TLV

   This OPTIONAL TLV is only valid in the Peer Initialization signal,
   and indicates that any destination addresses used during the lifetime
   of the session are not MAC addresses.  The length field specifies the
   length in octets of all destination identifiers to be used during the
   session.

   If the receiving DLEP router does not support this TLV then it SHOULD
   respond with a failure status in the corresponding Peer
   Initialization ACK signal as specified in the core DLEP
   specification.

   The Non MAC TLV contains the following fields:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |Length = 1                     | Id Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type:  TBD

   Length:  1

   Id Length:  The length in octets of destination identifiers.

2.2.  Destination Identifiers In Exisiting Data Items

   The MAC Address TLV can be present in several DLEP signals:
   Destination Up, Destination Up ACK, Destination Down, Destination
   Down ACK, Destination Update, Link Characteristics Request, and Link
   Characteristics ACK.  With this extension the use of the MAC Address
   TLV remains the same, but its format is adjusted.  This adjustment is
   backwards-compatible with the core DLEP specification.

   The MAC Address TLV is updated as follows:





Taylor & Dowdell         Expires January 1, 2015                [Page 4]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = TBD | Length > 0 (6)                |   Dest ID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Destination Identifier (cont...)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type:  TBD (Same as DLEP core specification)

   Length:

         0 (As specified in Non MAC TLV if present, else 6)

   Destination Identifier:  Unique identifier of the destination.

3.  External Route Advertisement

   A modem operating as a layer-3 routing device may well have one or
   more accessible subnets addressable from a neighbouring modem, and it
   is often the case that these accessible routes need to be advertised
   throughout the radio net.  To facilitate this advertisement, this
   specification includes the Route TLV.

   The purpose of the external route advertisement is not to convert
   DLEP into a routing protocol but rather to enable routes to be
   advertised during the DLEP session.  The method for discovering and
   propogating routes around the network is out of the scope of this
   document.

   Using the Route TLV, an attached router can receive information about
   routes external to a peer router at a DLEP destination via the
   Destination Up and Destination Update signals.  An attached peer
   router may also inject new routes in the DLEP session by using the
   Route TLV in the Peer Initialization and Peer Update signals.  The
   Route TLV may be included in any DLEP signal where an IPv4 or IPv6
   Address TLV may be used: Destination Up, Destination Update, Peer
   Initialization, and Peer Update signals.

   Because external routes may be sourced from running routing protocol
   instances, this extension re-uses the structure and type codes of the
   UPDATE message specified in BGP-4 [RFC4271].  It is the opinion of
   the authors that BGP provides a common denominator in routing
   functionality and avoids the requirement for new IANA registries for
   data items already in use by BGP.

   Unlike a BGP-4 UPDATE message, a Route TLV data item also allows the
   provision of DLEP metrics for an external route.  These metrics MUST



Taylor & Dowdell         Expires January 1, 2015                [Page 5]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


   follow all the rules for core DLEP metric data items.  It should be
   noted that the metrics describe the state of the link between the
   destination router and the source of the route and MUST NOT include
   or aggregate the metrics for the link between the DLEP destination
   and the local modem with the metrics for the external route.  This
   ensures that the responsibility for accumulating metrics for routes
   is with attached routers and not modems.

3.1.  Route TLV

   The Route TLV is an OPTIONAL data item.  It is also made up of
   several OPTIONAL components.  Its layout is heavilly influenced by
   the structure of the BGP-4 UPDATE message.

   The Route TLV contains the following fields:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = TBD | Length                        |   Withdrawn   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Routes Length |  Withdrawn Routes (variable)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Total Path Attributes Length  | Path Attributes (variable)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Total Metrics Length          | Route Metrics (variable)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Network Layer Reachability Information (variable)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type:  TBD

   Length:  Variable

   Withdrawn Routes Length:  As BGP-4 UPDATE Message

   Withdrawn Routes:  As BGP-4 UPDATE Message

   Total Path Attribute Length:  As BGP-4 UPDATE Message

   Path Attributes:  As BGP-4 UPDATE Message

   Total Metrics Length:  This 2-octets unsigned integer indicates the
      total length of the DLEP metric data item TLVs in octets.  A value
      of 0 indicates that there is no metric information included in
      this route TLV.





Taylor & Dowdell         Expires January 1, 2015                [Page 6]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


   Route Metrics:  This variable length field contains a list of DLEP
      metric TLV data items, such as Maximum Data Rate (Receive).  There
      MUST NOT be duplicate entries.

   Network Layer Reachability Information:  As BGP-4 UPDATE Message

4.  Security Considerations

   As an extension to the core DLEP protocol, the security
   considerations of that protocol apply to this extension.  This
   extension adds no additional security mechanisms or features.

   General BGP security considerations are discussed in [RFC4271] and
   [RFC4272].

5.  IANA Considerations

   This section specifies requests to IANA.

5.1.  Registration

   This specification defines new DLEP TLVs that require new number
   assignment from the DLEP Data Items repository:

   o  Non MAC TLV

   o  Route Advertisement TLV

6.  Normative References

   [DLEP]     Ratliff, S., Berry, B., Harrison, G., Jury, S., and D.
              Satterwhite, "Dynamic Link Exchange Protocol (DLEP)",
              draft-ietf-manet-dlep-05 , February 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
              4272, January 2006.

Authors' Addresses







Taylor & Dowdell         Expires January 1, 2015                [Page 7]


Internet-Draft         Layer-3 Extensions to DLEP              June 2014


   Rick Taylor
   Airbus Defence & Space
   Quadrant House
   Celtic Springs
   Coedkernew
   Newport  NP10 8FZ
   UK

   Email: rick.taylor@cassidian.com


   John Dowdell
   Airbus Defence & Space
   Quadrant House
   Celtic Springs
   Coedkernew
   Newport  NP10 8FZ
   UK

   Email: john.dowdell@cassidian.com































Taylor & Dowdell         Expires January 1, 2015                [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/