Using CLA-Specific Endpoint IDs to identify Channel Endpoint
draft-loiseau-dtn-cla-eid-00

Abstract

This document describes a specific EID scheme namely "cla" that meets the requirement for endpoint identification as defined in the Bundle Protocol and that also uniquely identifies a Convergence Layer Adapter "channel" and is, in essence, an interface identifier (IID). Such IID is comprised of two parts: a "cla-identifier" part that identifies a specific convergence layer adapter, and a "cla-parameters" part that is a cla-specific list of parameter describing a single channel managed by this convergence layer adapter.

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 https://datatracker.ietf.org/drafts/current/.

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 May 25, 2019.

Copyright Notice

Copyright (c) 2018 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 (https://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. Convention used in this document
• 3. IID: Scheme Syntax and Rules
• 4. CLA Additional Services
• 4.1. IID as an Egress Identifier
• 4.2. IID as an Ingress Identifier
• 5. IIDs Examples
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

This document describes a specific EID scheme namely "cla" that meets the requirement for endpoint identification as defined in the Bundle Protocol[I-D.ietf-dtn-bpbis] and that is managed by convergence layer adapters (CLA). Such EID of the scheme "cla" is called an Interface Identifier (IID) and within the context of the bundle protocol operation is used to identify channel endpoints. A Bundle Protocol Interface represents the abstraction of an underlying transport channel, managed by a CLA, and that provides the set of services described in section 7.2 of [I-D.ietf-dtn-bpbis]. A convergence layer adapter that conforms to this specification SHALL provide the two additional services:

1. egress: MUST provide an IID for every channel that is open and for which an interface is available for sending bundles.
2. ingress: If applicable, MAY provide an IID identifying the local Bundle Node for every channel that is open.

2. Convention used in this document

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 [RFC2119].

3. IID: Scheme Syntax and Rules

The general syntax of an IID is:

cla:<CLA-NAME>:<CLA-SPECIFIC-PART>

CLA-NAME is the name of the convergence layer adapter that can parse or generate this IID.

CLA-SPECIFIC-PART is the convergence layer specific part that identifies a specific cla channel. This part must be unambiguous and can be automatically guessed by any peer implementing this CLA and that knows the parameter for this channel.

4. CLA Additional Services

4.1. IID as an Egress Identifier

Convergence layer adapters provide a service interface used to send and receive Bundle with other Bundle Nodes. In this context, an IID identifies an interface in a way that is unambiguous meaning that two different interfaces should never have the same IID. IIDs being transport-layer interface identifier MUST exactly map to an underlying transport channel. Such IID is, in effect, used to identify the egress part of an interface.

Every Bundle that is schedule for forwarding and whose destination EID matches an egress-IID must be directly forwarded to the underlying matching transport channel.

4.2. IID as an Ingress Identifier

When applicable, a bundle node may be addressable in a way that is specific to a convergence layer adapter. For instance with stcp[I-D.burleigh-dtn-stcp] each bundle node can be uniquely identified with its pair {ip address, tcp port} and other bundle nodes may use an IID to address bundles to it. In some other case, it may not be possible to create such an identifier, for instance with a USB cla (where the transport channel is a folder in a USB drive), it wouldn't really make much sense to have a cla-specific address that would be automatically derivable by other bundle node. Such IID is, in effect, used to identify the ingress part of an interface.

If it is applicable to derive such ingress-IID to address the local bundle node instance, each bundle that is received and whose destination field is this IID should be processed for local delivery.

5. IIDs Examples

This appendix provides some examples for IIDs.

                    
                    cla:stcp:10.1.123.1:4556
                    
                

Figure 1: STCP-specific EID identifying an Interface to another Bundle Node with its IP address and TCP port

                    
                    cla:usb:1d6b:0002:folder1
                    
                

Figure 2: USB-specific EID identifying an Interface over a mounted usb device described as its bus address and folder

                    
                    cla:mailcl:xxxx@ietf.org:[dtn]
                    
                

Figure 3: MAILCL-specific EID that identifies a channel over SMTP protocol described as a mail address and subject filter

6. References

6.1. Normative References

6.2. Informative References

Author's Address