]> The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 US +1 443 778 7423 Edward.Birrane@jhuapl.edu

Johns Hopkins Applied Physics Laboratory

Emery.Annis@jhuapl.edu

General Delay-Tolerant Networking DTN Network Management Naming Addressing This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Autonomous Management Model (AMM), in support of challenged network management solutions described in the Delay-Tolerant Networking Autonomous Management Architecture (AMA). This document defines a new AMM Resource Identifier (ARI), based on the structure of a common URI, meeting the needs for a concise, typed, parameterized, and hierarchically organized set of data elements.

Introduction The unique limitations of Delay-Tolerant Networking (DTN) transport capabilities necessitate increased reliance on individual node behavior. These limitations are considered part of the expected operational environment of the system and, thus, contemporaneous end-to-end data exchange cannot be considered a requirement for successful communication. The primary DTN transport mechanism, Bundle Protocol version 7, (BPv7) , standardizes a store-and-forward behavior required to communicate effectively between endpoints that may never co-exist in a single network partition. BPv7 might be deployed in static environments, but the design and operation of BPv7 cannot presume that to be the case. Similarly, the management of any BPv7 protocol agent (BPA) (or any software reliant upon DTN for its communication) cannot presume to operate in a resourced, connected network. Just as DTN transport must be delay-tolerant, DTN network management must also be delay-tolerant. The DTN Autonomous Management Architecture (DTN AMA) outlines an architecture that achieves this result through the self-management of a DTN node as configured by one or more remote managers in an asynchronous and open-loop system. An important part of this architecture is the definition of a conceptual data schema for defining resources configured by remote managers and implemented by the local autonomy of a DTN node. The DTN Asynchronous Management Model (DTN AMM) defines a logical schema that can be used to represent data types and structures, autonomous controls, and other kinds of information expected to be required for the local management of a DTN node. The DTN AMM further describes a physical data model, called the Application Data Model, that can be defined in the context of applications to create resources in accordance with the DTN AMM logical schema. These named resources can be predefined in moderated publications or custom-defined as part of the operational management of a network or a node. Every AMM resource must be uniquely identifiable. To accomplish this, an expressive naming scheme is required. The AMM Resource Identifier (ARI) provides this naming scheme. This document defines an ARI, based on the structure of a URI, meeting the needs for a concise, typed, parameterized, and hierarchically organized naming convention.

Scope The ARI scheme is based on the structure of a URI in accordance with the practices outlined in . ARIs are designed to support the identification requirements of the DTN AMM logical schema. As such, this specification will discuss these requirements to the extent necessary to explain the structure and use of the ARI syntax. This specification does not constrain the syntax or structure of any existing URI (or part thereof). As such, the ARI scheme does not impede the ownership of any other URI definition and is therefore clear of the concerns presented in . This specification does not discuss the manner in which ARIs might be generated, populated, and used by applications. The operational utility and configuration of ARIs in a system are described in other documents associated with DTN management, to include the AMA and AMM specifications. This specification does not describe the way in which path prefixes associated with an ARI are standardized, moderated, or otherwise populated. Path suffixes may be specified where they do not lead to collision or ambiguity. This specification does not describe the mechanisms for generating either standardized or custom ARIs in the context of any given application, protocol, or network. This specification does not describe the ways in which an ARI could be encoded into other formats, to include compressed binary formats. However, the design of the ARI syntax discusses compressibility to the extent that the design impacts the ability to create such encodings.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology

• DTN Autonomous Management Model (AMM) - data types and data structures needed to manage applications in challenged networks.
• AMM Resource Identifier (ARI) - A unique identifier for any AMM object, syntactically conformant to the Uniform Resource Identifier (URI) syntax documented in and using the scheme name "ari".
• AMM Namespace - A moderated, hierarchical taxonomy of namespaces that describe a set of AMM scopes. Specifically, an individual AMM namespace is a specific sequence of AMM namespaces, from most general to most specific, that uniquely and unambiguously identify the namespace of a particular AMM.
• Operational Data Model (ODM) - The operational configuration of an Agent. This includes the union of all ADM information supported by the Agent as well as all operational, dynamic configuration applied to the Agent by Managers in the network.

ARI Scheme Utility AMM resources are referenced in the context of autonomous applications on an agent. The naming scheme of these resources must support certain features to inform AMA processing in accordance with the AMM logical schema. This section defines the set of unique characteristics of the ARI scheme, the combination of which provides a unique utility for naming. While certain other naming schemes might incorporate certain elements, there are no such schemes that both support needed features and exclude prohibited features.

Resource Parameterization The AMM schema allows for the parameterization of resources to both reduce the overall data volume communicated between DTN nodes and to remove the need for any round-trip data negotiation. Parameterization reduces the communicated data volume when parameters are used as filter criteria. By associating a parameter with a data source, data characteristic, or other differentiating attribute, DTN nodes can locally process parameters to construct the minimal set of information to either process for local autonomy or report to remote managers in the network. Parameterization eliminates the need for round-trip negotiation to identify where information is located or how it should be accessed. When parameters define the ability to perform an associative lookup of a value, the index or location of the data at a particular DTN node can be resolved locally as part of the local autonomy of the node and not communicated back to a remote manager.

Compressible Structure The ability to encode information in very concise formats enables DTN communications in a variety of ways. Reduced message sizes increase the likelihood of message delivery, require fewer processing resources to secure, store, and forward, and require less resources to transmit. While the encoding of an ARI is outside of the scope of this document, the structure of portions of the ARI syntax lend themselves to better compressibility. For example, DTN AMM encodings support the ability to identify resources in as few as 3 bytes by exploiting the compressible structure of the ARI. The ARI syntax supports three design elements to aid in the creation of more concise encodings: relative paths, path suffixing, and patterning.

Relative Paths Hierarchical structures are well known to support compressible encodings by strategically enumerating well-known branching points in a hierarchy. For this reason, the ARI syntax uses the URI path to implement a naming hierarchy. Supporting relative paths allow for the ARI namespace to be shortened relative to a well-known prefix. By eliminating the need to repeat common path prefixes in ARIs (in any encoding) the size of any given ARI can be reduced. This relative prefix might be relative to an existing location, such as the familiar "../item" or relative to a defined nickname for a particular path prefix, such as "{root}/item".

Path Suffixing Path suffixing refers to specifying how information close to the "leaf" node of a hierarchy is structured. By codifying this structure into the ARI syntax, elements of the AMM logical scheme can be enumerated and compressed in the same way for any physical data model instantiation of an ARI.

Patterning Patterning in this context refers to the structuring of ARI information to allow for meaning data selection as a function of wildcards, regular expressions, and other expressions of a pattern. Patterns allow for both better compression and fewer ARI representations by allowing a single ARI pattern to stand-in for a variety of actual ARIs. This benefit is best achieved when the structure of the ARI is both expressive enough to include information that is useful to pattern match, and regular enough to understand how to create these patterns.

ARI Component Definitions This section describes the components of the ARI scheme to inform the discussion of the ARI syntax in Section . These components include ARI Namespaces, Object Names, Parameters, and Special Representations.

Namespaces AMM resources exist within namespaces to eliminate the chance of a conflicting resource name, aid in the application of patterns, and improve the compressibility of the ARI. Namespaces MUST NOT be used as a security mechanism. An Agent or Manager MUST NOT infer security information or access control based solely on namespace information in an ARI. The AMM defines two types of namespaces whose representation within an ARI is slight different: Regular Namespaces and Anonymous Namespaces.

Anonymous Namespaces The ARI syntax supports the definition of AMM resources absent a containing namespace. In this sense, the resource is considered "anonymous" in that it is not placeable in a particular hierarchy and, thus, not able to be located based on relative paths, patterns over the namespace hierarchy, or other characteristic based on the namespace. Anonymous namespaces are most effectively used for the representation of literal values and constants that have utility and definition that is not otherwise associated with a single namespace. For example, the representation of the strongly typed integer value 4 could be representing using the anonymous namespace as: ari:uint(4)

Regular Namespaces A regular namespace is simply any namespace other than the empty namespace reserved for anonymous ARIs. Namespaces are hierarchical, which allows the grouping of resources that share common attributes - for example, resources associated with related protocols may have protocol-specific namespaces that are grouped under a single encompassing namespace. Namespaces that are closer to a "root node" in a hierarchy have broader scope than namespaces closer to "leaf nodes" in the same hierarchy. In a hierarchical model of namespaces, a particular namespace is identified as the path to that namespace through the hierarchy. The ARI encodes this path with the URI path attribute. The ARI scheme defines two types of namespaces: moderated and informal.

Moderated Namespaces Moderated namespaces identify AMM resources that have been defined in a normative, moderated way by some standards organization. These resources are immutable and can be relied on the be define and used the same way across multiple networks and multiple implementations. Because the source of the resource definition in a moderated namespace represents an authoritative reference to this object, moderated namespaces always include an authority segment.

Informal Namespaces Informal namespaces represent resources that are only defined in the context of a specific network, mission, or application or those resources that might only be defined for a certain period of time. Unlike moderated namespaces, informal namespaces have no defined authority associated with them. The path representing these namespaces may be any valid path. The general form of an informal namespace is given as: <ISSUER>/<TAG>. An Issuer is any string that identifies the organization that is defining an AMM object. This value may come from a global registry of organizations, an issuing node address, a signed known value, or some other network-unique marking. Issuers MUST NOT conflict with known moderated namespaces, and AMA Agents and Managers should not process Issuers that conflict with existing moderated namespaces. A Tag is any (optional) string used to disambiguate AMM Objects for an Issuer. The contents of the tag are left to the discretion of the Issuer. Examples of potential tag values include an issuer-known version number or a (signed) hashing of the data item associated with the reference identifier.

Object An object is any one of a number of data elements defined for the management of a given application or protocol that conforms to the AMM logical schema. Objects are identified in the ARI scheme by the catenation of their AMM logical schema type and a string name. Additionally, objects may be further differentiated by any parameters defined for that object.

Parameters The AMM logical schema allows many object types to be parameterized when defined in the context of an application or a protocol. If two instances of an AMM resource have the same namespace and same object type and object name but have different parameter values, then those instances are unique and the ARIs for those instances MUST also be unique. Therefore, parameters are considered part of the ARI syntax. The AMM logical schema defines two types of parameters: Formal and Actual. The terms formal parameter and actual parameter follow common computer programming vernacular for discussing function declarations and function calls, respectively.

Formal Parameters Formal parameters define the type, name, and order of the information that customizes an ARI. They represent the unchanging "definition" of the parameterized object. Formal parameters MUST include type and name information and MAY include an optional default value. If specified, a default value will be used whenever a set of actual parameters fails to provide a value for this formal parameter.

Actual Parameters Actual parameters represent the data values used to distinguish different instances of a parameterized object. An actual parameter MUST specify a value and MAY specify a type. If a type is provided it MUST match the type provided by the formal parameter. An actual parameter MUST NOT include NAME information. Including type information in an actual parameters allows for explicit type checking of a value, which might otherwise be implicitely cast. There are two ways in which the value of an actual parameter can be specified: parameter-by-value and parameter-by-name.

Parameter-By-Value

This method involves directly supplying the value as part of the actual parameter. It is the default method for supplying values.

Parameter-By-Name

This method involves specifying the name of some other parameter and using that other parameter's value for the value of this parameter. This method is useful when a parameterized ARI contains another parameterized ARI. The contained object's actual parameter can be given as the name of the containing ARI's parameter. In that way, a containing ARI's parameters can be "flowed down" to all of the objects it contains.

NOTE: In cases where a formal parameter contains a default value, the associated actual parameter may be omitted. Default values in formal parameters (and, thus, optional actual parameters) are encouraged as they reduce the size of data items communicated amongst Managers and Agents in a network.

Special Case: Literal Values A literal value is one whose value and name are equivalent. The name is, literally, the value. For example, the literal "4" serves as both a name and a value. When literal values are represented, the object name MUST be omitted and the literal value substituted as a parameterization of the object. Further, because the value of a Literal serves as its name, there is no need for regular namespaces. All literals exist in the anonymous namespace.

ARI Scheme Syntax There are three components to the ARI: namespaces, objects, and parameters. This section defines the syntactic representation of each of these components, and discusses special cases. The scheme name of the ARI is "ari". The scheme-specific part of the "ari" scheme follows the format: ari:/<Namespace>/<Object><(Parameters)> The string representation of each component is given as follows.

Namespaces

Namespaces are represented as "/" separated lists, with individual namespace types represented as follows:

• Moderated namespaces are listed using a URI authority representing the normative moderator for the resource followed by a URI path relative to that moderator. For example: "ari://sdo/ietf/dtn/adm/bp/".
• Anonymous namespaces are empty and are represented as the lack of a starting / or //. For example: "ari:type.name(parm)".
• Informal namespaces are URI paths without a URI authority present. For example: "ari:/myproject/dtn/bp/dynamic".

Objects

The object name is represented as the two-tuple of the object type and the object name, joined with the '.' character. For example: "uint.num_bundles".

Parameters

If present, parameters are represented as a comma-separated string enclosed in parenthesis. Different types of parameters are represented as follows.

• Formal parameters follow the pattern <type> <name> and if there is a default value, it is represented by the substring "= <value>".
• Actual Parameters-By-Value are represented as the string encoding of their value.
• Actual Parameters-By-Name are represented as the name of the parameter enclosed in angle brackets.

Note: If an actual parameter is missing for a formal parameter that has a default value, then the ARI MUST have a blank space where the actual parameter would have been. This missing parameter will also have a comma, separating it from other actual parameters in the ARI string.

Literal String Encoding The string representation of a Literal ARI is much simpler and consists of simply the data type of the Literal followed by the value, as follows: "ari:/type(value)"

Delimiting Characters For the scheme specific parts, there is no authority to be defined for the ARI URI. The scheme is separated from the path using a ":" and the path components are separated and terminated using a "/". The path is comprised of the namespaces which hierarchally organize the AMM objects. The object is defined by both its AMM object type (such as EDD, VAR, RPTT, etc.) and the object name, each separated by a ".". The object parameters are separated using reserved characters "{", "}", "[", "]", "(", ")" described below. Finally the "#" sign is used at the end of the ARI only in cases where custom issuer specific objects are defined. Example = ari:/top-a/mid-c/low-b/edd.dtnObject([int dtnObjParam1], [str dtnObjParam2])#custom-issuer-1

Wildcards TBD

Encoding Considerations ARIs might be represented in a variety of different formats, to include human-readable strings, structured language representations (such as XML or JSON), and binary encodings (such as CBOR). An ARI scheme must support the mechanical translation amongst this diversity of representations. An ARI scheme should represent, and differentiate, different kinds of information using a standard format. Such standard formats should rely on delimiters and other structural components and not informal naming conventions.

Scheme Registration Considerations This section contains fields required for the URI scheme registration, following the guidelines in TODO: Define characters used for globs, wildcards, expression matching, etc.

Interoperability Considerations DTN challenged networks might interface with better resourced networks that are managed using non-DTN management protocols. When this occurs, the federated network architecture might need to define management gateways that translate between DTN and non-DTN management approaches. NOTE: It is also possible for DTN management be used end-to-end because this approach can also operate in less challenged networks. The opposite is not true; non-DTN management approaches should not be assumed to work in DTN challenged networks. Where possible, ARIs should be translatable to other, non-DTN management naming schemes. This translation might not be 1-1, as the features of the AMM may differ from features in other management naming schemes. Therefore, it is unlikely that a single naming scheme can be used for both DTN and non-DTN management.

Security Considerations Policy decisions as to whether anonymous namespaces are allowed in the system should be determined before network deployment. The use of an anonymous namespace greatly increases the chances of naming collisions. Because informal namespaces are defined by any entity, no security or permission meaning can be inferred simply from the expression of namespace.

IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of schema and namespaces related to the AMM Resource Identifier (ARI), in accordance with BCP 26 .

ARI Scheme This document defines a new URI scheme, "ari", as defined in . This scheme to be registered by IANA here: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. This Internet Draft presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050. Informative References This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK] This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community. Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards. Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic. This document provides guidance on the specification of URI substructure in standards. This document obsoletes RFC 7320 and updates RFC 3986. Johns Hopkins Applied Physics Laboratory Johns Hopkins Applied Physics Laboratory Johns Hopkins Applied Physics Laboratory This document describes a management architecture suitable for deployment in challenged networking environments for the configuration, monitoring, and local control of application services. Challenged networking environments exhibit interruptions in end-to- end connectivity and communications delays that are both long-lived and unpredictable. Even in these challenging conditions, such networks must provide some type of end-to-end information transport and fault protection while also supporting configuration and performance reporting. This management may need to operate without human- or system-in-the-loop synchronous interactivity and without the preservation of transport-layer sessions. In such a context, challenged networks must exhibit behavior that is both determinable and autonomous while maintaining as much compatibility with non- challenged-network operational concepts as possible. The architecture described in this document is termed the Asynchronous Management Architecture (AMA). The AMA supported two types of asynchronous behavior. First, the AMA does not presuppose any synchronized transport behavior between managed and managing devices. Second, the AMA does not support any query-response semantics. In this way, the AMA allows for operation in extremely challenging conditions, to include over uni-directional links and cases where delays/disruptions would otherwise prevent operation over traditional transport layers, such as when exceeding the Maximum Segment Lifetime (MSL) of the Transmission Control Protocol (TCP). This document defines a physical data model that captures the information necessary to asynchronously manage applications. This model provides a set of common type definitions, data structures, and a template for publishing standardized representations of model elements.

Examples

Namespace Examples For example, consider the namespaces in . ARI Namespace Hierarchy

+-------+ +--------+ | SDO | | VENDOR | +---+---+ +---+----+ | _____|_____ | | | +-------+ +-------+ +-------+ | IETF | | PROD1 | | PROD2 | +-------+ +-------+ +-------+ _________|_________ | | | | | | | +-------+ +-------+ +-------+ +-------+ +-------+ | APP-1 | | APP-2 | | APP-3 | | APP-4 | | APP-5 | +-------+ +-------+ +-------+ +-------+ +-------+

Given this hierarchy, the following are all valid namespace representations.

• ari://sdo/ietf/
• ari://sdo/ietf/app-1/
• ari://sdo/ietf/app-3/
• ari:/vendor/
• ari:/vendor/prod1/
• ari:/vendor/prod2/app-5
• ari:/

Object Examples The ARIs for the following sample AMM objects are encoded in . Note that these examples are for the identifiers of AMM objects, not their entire definition.

• The number of bytes received by an Agent, defined in the N1/N2 namespace and called num_bytes.
• The number of bytes received through an interface, called num_bytes_if, which takes a single string parameter named "if_name" with a default value oth "eth0".
• An anonymous, operator-defined object named "obj1" which takes two unsigned integer parameters, n1 and n2, with default values of 3 and 4, respectively.
• The typed, Literal value of 4.

ARI String	Description
"ari:/N1/N2/num_bytes"	Unparameterized num_bytes object in the N1/N2 informal namespace.
"num_bytes"	Shortform encoding where the N1/N2 namespace can be assumed.
"num_bytes_if(String if_name)"	Formal parameter definition of num_bytes object that accepts a string interface name.
"num_bytes_if(String if_name=eth0)"	Formal parameter definition of num_bytes object that accepts a string interface name with a default value.
"num_bytes_if()"	Actual parameter using the default value of eth0.
"num_bytes_if(eth0)"	Actual parameter of eth0.
"ari:/obj1(Int n1 = 0, Int n2 = 3)"	Formal parameter of object obj1 in anonymous namespace taking 2 default parameters.
"ari:/obj1(, )"	Actual parameter using the default values of 0 for n1 and 3 for n2.
"ari:/obj1(, 4)"	Actual parameter using the default value of 0 for n1.
"ari:/obj1(4, )"	Actual parameter using the default value of 3 for n2.
"ari:/obj1(4,4)"	Actual parameters provided for all obj1 parameters.
"ari:/obj1(<input>,4)"	Actual parameters provided for all obj1 parameters, with the value of the first parameter taken from some other parameter named "input".
"ari:uint(4)"	The Literal value 4 interpreted as a 32-bit unsigned integer.