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.