[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
 INTERNET DRAFT                                       Benson Schliesser
 CATEGORY: Experimental                                 David Brissette
 Expires: July 2002                                         Tim Zollner
 draft-bensons-nodp-00.txt                        SAVVIS Communications
 
                                                          Elwin Eliazer
                                                        Corona Networks
 
 
 
 
                                                          February 2002
 
 
 
 
         The Network Overlay Discovery Protocol (NODP)
 
 
 
 
 
 Status of this Memo
 
    This document is an Internet-Draft and is subject to
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.
 
    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."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/1id-abstracts.html
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html
 
 
 
 
 Abstract
 
    This document presents a mechanism for Auto-Discovery of membership
    topology and capability information for network overlays. The
    mechanism described herein is referred to as the Network Overlay
    Discovery Protocol (NODP).
 
 
 Table of Contents
 
    ...
 
 
 1. Introduction
 
    This document presents a mechanism for Auto-Discovery of membership
    topology and capability information for network overlays. The
    mechanism described herein is referred to as the Network Overlay
    Discovery Protocol (NODP).
 
    Applications of this mechanism may include PPVPN Auto-Discovery and
    Discovery of IPv6 or IP Multicast overlay networks.
 
    The protocol specified here is intended to be expandable,
    backwards-compatible, and interworkable with other architectures.
    As such, it is intended to be used for both intra- and inter- SP
    network overlays
 
    It is designed to run as a payload within an underlying distribution
    protocol. It is assumed that the underlying distribution protocol will
    account for redistribution requirements (ie., flooding), peer
    authentication, reliability, etc.
 
 
 1.1. PPVPN Auto-Discovery
 
    This protocol is intended to function as an Auto-Discovery mechanism
    for PPVPNs. [PPVPN-FW], [PPVPN-REQ]
 
    [PPVPN-FW] notes that Functional Components of a PPVPN are:
 
       o A mechanism to acquire overlay membership/capability information
 
       o A mechanism to tunnel traffic between overlay sites
 
       o For layer 3 PE-based overlays, a means to learn customer routes,
         distribute them across the provider network, and to advertise
         reachable destinations to customer sites.
 
    This document outlines a protocol intended to provide a
    "mechanism to acquire overlay membership/capability information". This
    does not assume that a particular mechanism will be used
    to tunnel traffic between overlay sites, nor does it provide a means to
    learn, distribute, or advertise customer routes. However, the means
    by which these functional components are accomplished may be indicated
    by this protocol as Capability information.
 
 
 2. Network Overlay Discovery Protocol Specification
 
 
 2.1. NODP Description
 
    NODP is a mechanism by which nodes such as P, PE, and CE nodes can
    discover the topology and capabilities of an overlay network. The
    topology of an overlay network can be understood to be the collection
    of members participating in an overlay network and a description of
    how they are to be interconnected. The capabilities of an overlay
    network can be understood to be additional attributes of the overlay,
    such as details of how members are to be interconnected, addressing
    policy, reachability distribution mechanisms, and others.
 
    Topology discovery is accomplished by flooding of Membership
    Advertisements. Each node participating in a NODP domain should
    send a Membership Advertisement to each of its NODP peers for for
    each of the overlay networks in which it will participate. Membership
    Advertisements received from a NODP peer by a node participating in a
    NODP domain should be redistributed to that nodes other NODP peers. If
    the receiving node may participate in the overlay network being
    advertised then it must save the advertisement locally in a topology
    database. This process eventually leads to a uniform view of overlay
    topology by all nodes which may participate in that overlay.
 
    Each Membership Advertisement must contain a set of Attributes
    describing the overlay capabilities of the advertising node. Attributes
    can be described as Required Attributes or Optional Attributes.
    Required Attributes are Attributes that must be advertised, and must be
    recognized by a receiving node in order for the Membership
    Advertisement to be considered valid. Optional Attributes are
    Attributes that may be advertised, and indicate capabilities of the
    advertising node that may be supported by receiving nodes.
 
    A Membership Advertisement may contain multiple Attributes of the same
    type. In this case, the node should choose which Attribute of that type
    will be used. If the node cannot support any of the Attributes of that
    type, then it may ignore them. However, if the Attribute type is a
    Required Attribute then the Membership Advertisement should not be
    considered valid. (see above)
 
    The underlying distribution protocol may determine topology of the
    NODP peering. The relationship between NODP peers does not necessarily
    reflect the relationship between any two members of the same overlay
    on different nodes. In other words, the topology of the overlay
    does not have to be the same as the topology of the NODP domain.
 
 
 2.2. NODP Membership Advertisement
 
    The following is a diagram of the NODP Membership Advertisement.
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    |            RESERVED           |Attribute Count|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         GID                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         GID (cont.)                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Auth                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Auth (cont.)                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Auth (cont.)                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Attribute 1                          ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Attribute n                          ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 2.2.1. Version
 
    The current Version is 1.
 
 
 2.2.2. Attribute Count
 
    The Attribute Count field indicates the number of attributes which will
    follow the NODP header. This value may be set to zero (0) if no
    Attributes are to follow the membership advertisement.
 
 
 2.2.3. GID Field
 
    The GID field indicates the Global Unique Identifier [GID] of the overlay
    for which membership is being advertised.
 
 
 2.3. NODP Attributes
 
    Zero or more Attributes may be included in a NODP advertisement,
    indicated by the Attribute Count field of the NODP header. The NODP
    Attribute(s) follow the NODP header, and have the following format:
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |            Value  ...         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 2.3.1. Type Field
 
    The Type field indicates the type of Attribute that is being
    specified. Attribute Types are described in section 3.
 
 
 2.3.2. Length Field
 
    The Length field indicates the size of the Value field, in Octets.
 
    An Attribute's size must be a multiple of 32 bits.
 
 
 2.3.3. Value Field
 
    The Value field is a variable length field, the format of which
    is determined by Type. The size of this field is indicated in
    octets by the Length field.
 
 
 3. Attributes
 
 
 3.1. Status Attribute
 
    The Status Attribute is assigned the Type of 1. The Status
    Attribute has the following format:
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=1     |   Length=2    | Status Type   | Status Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    The Attribute's Value field is composed of two sub-fields,
    Status Type and Status Value.
 
 
 3.1.1. Overlay Active Status Attribute
 
    The Overlay Active Status Attribute indicates whether the advertising
    node currently recognizes the indicated overlay as active or not.
 
    If an overlay formerly advertised as Up is transitioned to Down via this
    Attribute, all overlay connections to the advertising node must be terminated.
    Conversely, if an overlay formerly advertised as Down, or not advertised at
    all, is transitioned to Up via this Attribute, all nodes should attempt
    to connect to it via the advertised acceptible Methods in accordance
    with the overlay's advertised Topology Attribute, if any.
 
    Overlay Active Status Attribute is a Required Attribute.
 
    Status Type = 1
 
    Status Value:
 
      Down  = 0
      Up    = 1
 
 
 3.2. PPVPN-Type Attribute
 
    The PPVPN-Type Attribute indicates the type of PPVPN that is being
    advertised. The PPVPN-Type Attribute has the following format:
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=2     |   Length=2    |  PPVPN-Type   |   RESERVED    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    PPVPN-Type:
 
      L3 PE VR Based        = 1
      L3 PE BGP/MPLS Based  = 2
      L2 PE VPLS Based      = 3
      L3 CE IPSec Based     = 4
 
 
 3.3. Overlay Routing Protocol
 
    The Overlay Routing Protocol field indicates the route distribution
    method that will be used by the overlay, if any, and any additional
    parameters needed by the routing protocol. This attribute is
    expected to apply specifically to IP overlays, such as L3 PPVPNs.
 
    The Overlay Routing Protocol Attribute has the following format:
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=3     |    Length     |   Protocol    | Parameters... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    Protocol
      Static        = 0
      OSPF          = 1
      RIP           = 2
 
    The Parameters field of the Overlay Routing Protocol Attribute is used
    to distribute parameters needed to initiate the selected protocol.
 
 
 3.3.1. Static
 
    If the Protocol field of an Overlay Routing Protocol Attribute is set
    to 0, then the route distribution mechanism for the indicated overlay
    is static configuration of routing. No further setup of the route
    distribution mechanism is assumed to be necessary.
 
 
 3.3.2. OSPF
 
    If the Protocol field of an Overlay Routing Protocol Attribute is set
    to 1, then the route distribution mechanism for the indicated overlay
    is OSPF. The Parameters field should be one octet in length, making the
    Length field 2. The Parameters field must contain the OSPF Area that
    will be used in any adjacency which is established over the overlay Tunneling
    mechanism to the advertising node.
 
 
 3.3.3. RIP
 
    If the Protocol field of a Overlay Routing Protocol Attribute is set
    to 2, then the route distribution mechanism for the indicated overlay
    is RIP. The Parameters field should be one octet in length, making the
    Length field 2. The Parameters field must contain the RIP version
    that will be used in any adjacency which is established over the overlay
    Tunneling mechansim to the advertising node.
 
 
 3.4. Overlay Tunnel Methods
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=4     |    Length     |    Method     | Parameters... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 3.4.1. NULL Method
 
    Method = 0
    Parameters = 0
 
    The NULL Method indicates that an advertising node cannot accept Overlay Tunnel
    connections for the advertised overlay. If the NULL Method is included as an
    Attribute, then the advertisement must not contain any other Method
    Attributes. If a node receives a NULL Method Attribute in an Advertisement,
    it must ignore any other Method Attributes included in the Advertisement.
 
 
 3.4.2. PPP/L2TP/UDP/IPSec
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=4     |    Length     |   Method=1    |   LNS IP Ver  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | LNS IP                      ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Session Id (user id)        ...                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 3.5. Topology Attributes
 
    Topology Attributes indicate the advertising node's policy for
    overlay Tunnel interconnection.
 
    Multiple topologies are not allowed to be announced in a single
    Membership Advertisement.
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=5     |    Length     |   Topology    |   Parameters  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 3.5.1.  Full Mesh
 
   Full Mesh indicates that this node will accept tunnel connections of
   advertised tunnel type for advertised overlay from any authenticated node.
 
    0                   1                   2                   3
     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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=5     |   Length=2    |  Topology=1   |   RESERVED    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
 4. Security Considerations
 
    The Auth field value TBD.
 
 
 5. IANA Considerations
 
    IANA considerations are discussed in [GID].
 
 
 6. Acknowledgements
 
    Thanks to Paul Knight for his review and comments.
 
 
 7. References
 
 
    [GID]       Ould-Brahim, et al., "Global Unique Identifier",
                Internet Draft draft-ouldbrahim-ppvpn-gid-00.txt, February 2002.
 
    [PPVPN-FW]  Callon, R., Suzuki, M., et al., "A Framework for Provider
                Provisioned Virtual Private Networks", Work in Progress,
                Internet Draft draft-ietf-ppvpn-framework-03.txt, January 2002.
 
    [PPVPN-REQ] Carugi, et al., "Service requirements for Provider Provisioned
                Virtual Private Networks", Work in Progress, Internet Draft
                draft-ietf-ppvpn-requirements-03.txt, December 2001.
 
 
 8. Authors' Addresses
 
    Benson Schliesser
    SAVVIS Communications
    717 Office Parkway
    Saint Louis, MO 63141
    Phone: +1-314-468-7036
    Email: bensons@savvis.net
 
    David Brissette
    SAVVIS Communications
    717 Office Parkway
    Saint Louis, MO 63141
 
    Tim Zollner
    SAVVIS Communications
    717 Office Parkway
    Saint Louis, MO 63141
 
    Elwin Stelzer Eliazer
    Corona Networks, Inc.
    630 Alder Drive
    Milpitas, CA 95035
    Email: elwinietf@yahoo.com
 
 
 9.0 Full Copyright Statement
 
 
    Copyright (C) The Internet Society (2001). All Rights
    Reserved.
 
    This document and translations of it may be copied and
    furnished to others, and derivative works that comment on
    or otherwise explain it or assist in its implementation
    may be prepared, copied, published and distributed, in
    whole or in part, without restriction of any kind,
    provided that the above copyright notice and this
    paragraph are included on all such copies and derivative
    works.  However, this document itself may not be modified
    in any way, such as by removing the copyright notice or
    references to the Internet Society or other Internet
    organizations, except as needed for the purpose of
    developing Internet standards in which case the
    procedures for copyrights defined in the Internet
    Standards process must be followed, or as required to
    translate it into languages other than English.
 
    The limited permissions granted above are perpetual and
    will not be revoked by the Internet Society or its
    successors or assigns. This document and the information
    contained herein is provided on an "AS IS" basis and THE
    INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
    DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
    IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE.