Delay-Tolerant Networking E. Birrane
Internet-Draft E. DiPietro
Intended status: Experimental D. Linko
Expires: January 3, 2019 Johns Hopkins Applied Physics Laboratory
July 2, 2018

ION Application Data Model
draft-birrane-dtn-adm-ion-ipnadmin-00

Abstract

This document describes the Application Data Model (ADM) for the configuration of the routing of bundles to ipn endpoint ID scheme conformant endpoints from a local ION node. provided by [I-D.birrane-dtn-adm].

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 January 3, 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

An Application Data Model (ADM) provides a guaranteed interface for the management of an application or protocol in accordance with the Asynchronous Management Architecture (AMA) defined in [I-D.birrane-dtn-ama]. The ADM described in this document complies with the ADM Template provided in [I-D.birrane-dtn-adm] as encoded using the JSON syntax.

The ION IPN (Interplanetary Internet) Scheme Administration ADM contains all of the functionality that is required to configure the routing of bundles from a local node to an endpoint that conforms to the IPN scheme.

1.1. Technical Notes

1.2. Scope

This ADM specifies those components of the Asynchronous Management Model (AMM) common to the configuration of the IPN scheme in ION.

Any Manager software implementing this ADM MUST perform the responsibilities of an AMA Manager as outlined in [I-D.birrane-dtn-adm] as they relate to the objects included in this document.

Any Agent software implementing this ADM MUST perform the responsibilities of an AMA Agent as outlined in [I-D.birrane-dtn-adm] as they relate to the objects included in this document.

1.3. 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 RFC 2119.

2. Structure and Design of this ADM

The IPN Admin ADM's structure is in accordance to [I-D.birrane-dtn-adm]. This ADM contains metadata, edd, table templates, and controls. Externally Defined Data (EDD) are values that are calculated external to the ADM system. Table Templates are column templates that will be followed by any instance of this table available in the network. They may not be created dynamically within the network by Managers. Controls are predefined and sometimes parameterized opcodes that can be run on an Agent. Controls are preconfigured in Agents and Managers as part of ADM support.There are no variables, report templates, macros, constants, or operators in this ADM at this time. The contents of this ADM are derived from the main functions and data that are needed for configuration in accordance with the IPN scheme.

There are two categories of functions in IPN. They are ones that deal with egress plans (plans for unobstructed and continuous ways of exit travel) and ones that deal with exits for static default routing. These plans and exits are discussed throughout the ADM.

All ADMs have metadata that includes the name, namespace, and version of the ADM as well as the name of the organization that is issuing that particular ADM. This is important for identification purposes of the ADMs and to ensure version control. All of the functions that are related to the configuration of IPN in ION are present in this document.

3. Naming and Identification

This section outlines the namespaces used to uniquely identify ADM objects in this specification.

3.1. Namespace and Nicknames

In accordance with [I-D.birrane-dtn-adm], every ADM is assigned a moderated Namespace. In accordance with [I-D.birrane-dtn-amp], these namespaces may be enumerated for compactness. The namespace and ADM identification for these objects is defined as follows.

Namespace Information
Identifier Value
Namespace DTN/ION/ipnadmin
ADM Enumeration 6

Given the above ADM enumeration, in accordance with [I-D.birrane-dtn-amp], the following AMP nicknames are defined.

ION IPN Admin ADM Nicknames
Nickname Collection
120 DTN/ION/ipnadmin/Const
121 DTN/ION/ipnadmin/Ctrl
122 DTN/ION/ipnadmin/Edd
123 DTN/ION/ipnadmin/Mac
124 DTN/ION/ipnadmin/Oper
125 DTN/ION/ipnadmin/Rptt
127 DTN/ION/ipnadmin/Tblt
129 DTN/ION/ipnadmin/Var
130 DTN/ION/ipnadmin/Mdat
131-139 DTN/ION/ipnadmin/Reserved

4. ION IPN Admin ADM JSON Encoding

{
  "Mdat": [
    {
      "name": "name",
      "type": "STR",
      "value": "ion_ipn_admin",
      "description": "The human-readable name of the ADM."
    },
    {
      "name": "namespace",
      "type": "STR",
      "value": "DTN/ION/ipnadmin/",
      "description": "The namespace of the ADM"
    },
    {
      "name": "version",
      "type": "STR",
      "value": "v0.0",
      "description": "The version of the ADM"
    },
    {
      "name": "organization",
      "type": "STR",
      "value": "JHUAPL",
      "description": "The name of the issuing organization of the ADM"
    }
  ],
  "Edd": [
    {
      "name": "ion_version",
      "type": "STR",
      "description": "This is the version of ion is that currently 
        installed."
    }
  ],
  "Tblt": [
    {
      "name": "exits",
      "columns": [
        {"type":"UINT","name":"first_node_nbr"},
        {"type":"UINT","name":"last_node_nbr"},
        {"type":"STR","name":"gateway_endpoint_id"}
      ],
      "description": "This table lists all of the exits that are defined in 
        the IPN database for the local node."
    },
    {
      "name": "plans",
      "columns": [
        {"type":"UINT","name":"node_nbr"},
        {"type":"STR","name":"default_duct_expression"}
      ],
      "description": "This table lists all of the egress plans that are 
        established in the IPN database for the local node."
    }
  ],
  "Ctrl": [
    {
      "name": "exit_add",
      "parmspec": [
        {"type":"UINT","name":"first_node_nbr"},
        {"type":"UINT","name":"last_node_nbr"},
        {"type":"STR","name":"gateway_endpoint_id"}
      ],
      "description": "This control establishes an \"exit\" for static 
        default routing."
    },
    {
      "name": "exit_change",
      "parmspec": [
        {"type":"UINT","name":"first_node_nbr"},
        {"type":"UINT","name":"last_node_nbr"},
        {"type":"STR","name":"gatewayEndpointId"}
      ],
      "description": "This control changes the gateway node number for the 
        exit identified by firstNodeNbr and lastNodeNbr."
    },
    {
      "name": "exit_del",
      "parmspec":[
        {"type":"UINT","name":"first_node_nbr"},
        {"type":"UINT","name":"last_node_nbr"}
      ],
      "description": "This control deletes the exit identified by 
        firstNodeNbr and lastNodeNbr."
    },
    {
      "name": "plan_add",
      "parmspec": [
        {"type":"UINT","name":"node_nbr"},
        {"type":"STR","name":"default_duct_expression"}
      ],
      "description": "This control establishes an egress plan for the 
        bundles that must be transmitted to the neighboring node that is 
        identified by it's nodeNbr."
    },
    {
      "name": "plan_change",
      "parmspec": [
        {"type":"UINT","name":"node_nbr"},
        {"type":"STR","name":"default_duct_expression"}
      ],
      "description": "This control changes the duct expression for the 
        indicated plan."
    },
    {
      "name": "plan_del",
      "parmspec": [
        {"type":"UINT","name":"node_nbr"}
      ],
      "description": "This control deletes the egress plan for the node that
        is identified by it's nodeNbr."
    }
  ]
}

      

5. IANA Considerations

At this time, this protocol has no fields registered by IANA.

6. References

6.1. Informative References

[I-D.birrane-dtn-ama] Birrane, E., "Asynchronous Management Architecture", Internet-Draft draft-birrane-dtn-ama-07, June 2018.

6.2. Normative References

[I-D.birrane-dtn-adm] Birrane, E., DiPietro, E. and D. Linko, "AMA Application Data Model", Internet-Draft draft-birrane-dtn-adm-02, June 2018.
[I-D.birrane-dtn-amp] Birrane, E., "Asynchronous Management Protocol", Internet-Draft draft-birrane-dtn-amp-04, June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

Authors' Addresses

Edward J. Birrane Johns Hopkins Applied Physics Laboratory EMail: Edward.Birrane@jhuapl.edu
Evana DiPietro Johns Hopkins Applied Physics Laboratory EMail: Evana.DiPietro@jhuapl.edu
David Linko Johns Hopkins Applied Physics Laboratory EMail: David.Linko@jhuapl.edu