Internet DRAFT - draft-bensons-nodp
draft-bensons-nodp
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.
