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]