Layer-3 Extensions to DLEP

The Dynamic Link Exchange Protocol 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, 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.

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 .

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 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.

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD 1 The length in octets of destination identifiers.

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:

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...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD (Same as DLEP core specification) 0 (As specified in Non MAC TLV if present, else 6) Unique identifier of the destination.

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 . 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 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.

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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TBD Variable As BGP-4 UPDATE Message As BGP-4 UPDATE Message As BGP-4 UPDATE Message As BGP-4 UPDATE Message 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. 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. As BGP-4 UPDATE Message

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 and .

This section specifies requests to IANA.

This specification defines new DLEP TLVs that require new number assignment from the DLEP Data Items repository: Non MAC TLV Route Advertisement TLV