doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4208.txt b/doc/rfc/rfc4208.txt
new file mode 100644
index 0000000..e1173a9
--- /dev/null
+++ b/doc/rfc/rfc4208.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                         G. Swallow
+Request for Comments: 4208                            Cisco Systems, Inc
+Category: Standards Track                                       J. Drake
+                                                                  Boeing
+                                                            H. Ishimatsu
+                                                           G1M Co., Ltd.
+                                                              Y. Rekhter
+                                                   Juniper Networks, Inc
+                                                            October 2005
+
+
+           Generalized Multiprotocol Label Switching (GMPLS)
+                     User-Network Interface (UNI):
+      Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
+                     Support for the Overlay Model
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   Generalized Multiprotocol Label Switching (GMPLS) defines both
+   routing and signaling protocols for the creation of Label Switched
+   Paths (LSPs) in various switching technologies.  These protocols can
+   be used to support a number of deployment scenarios.  This memo
+   addresses the application of GMPLS to the overlay model.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swallow, et al.             Standards Track                     [Page 1]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. GMPLS User-Network Interface (GMPLS UNI) ...................4
+   2. Addressing ......................................................5
+   3. ERO Processing ..................................................6
+      3.1. Path Message without ERO ...................................6
+      3.2. Path Message with ERO ......................................6
+      3.3. Explicit Label Control .....................................7
+   4. RRO Processing ..................................................7
+   5. Notification ....................................................7
+   6. Connection Deletion .............................................8
+      6.1. Alarm-Free Connection Deletion .............................8
+      6.2. Connection Deletion with PathErr ...........................8
+   7. VPN Connections .................................................9
+   8. Security Considerations ........................................10
+   9. Acknowledgments ................................................10
+   10. References ....................................................10
+      10.1. Normative References .....................................10
+      10.2. Informational References .................................10
+
+1.  Introduction
+
+   Generalized Multiprotocol Label Switching (GMPLS) defines both
+   routing and signaling protocols for the creation of Label Switched
+   Paths (LSPs) in various transport technologies.  These protocols can
+   be used to support a number of deployment scenarios.  In a peer
+   model, edge-nodes support both a routing and a signaling protocol.
+   The protocol interactions between an edge-node and a core-node are
+   the same as between two core-nodes.  In the overlay model, the core-
+   nodes act more as a closed system.  The edge-nodes do not participate
+   in the routing protocol instance that runs among the core nodes; in
+   particular, the edge-nodes are unaware of the topology of the core-
+   nodes.  There may, however, be a routing protocol interaction between
+   a core-node and an edge-node for the exchange of reachability
+   information to other edge-nodes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swallow, et al.             Standards Track                     [Page 2]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+     Overlay                                                  Overlay
+     Network       +----------------------------------+       Network
+   +---------+     |                                  |     +---------+
+   |  +----+ |     |  +-----+    +-----+    +-----+   |     | +----+  |
+   |  |    | |     |  |     |    |     |    |     |   |     | |    |  |
+   | -+ EN +-+-----+--+ CN  +----+ CN  +----+  CN +---+-----+-+ EN +- |
+   |  |    | |  +--+--|     |    |     |    |     |   |     | |    |  |
+   |  +----+ |  |  |  +--+--+    +--+--+    +--+--+   |     | +----+  |
+   |         |  |  |     |          |          |      |     |         |
+   +---------+  |  |     |          |          |      |     +---------+
+                |  |     |          |          |      |
+   +---------+  |  |     |          |          |      |     +---------+
+   |         |  |  |  +--+--+       |       +--+--+   |     |         |
+   |  +----+ |  |  |  |     |       +-------+     |   |     | +----+  |
+   |  |    +-+--+  |  | CN  +---------------+ CN  |   |     | |    |  |
+   | -+ EN +-+-----+--+     |               |     +---+-----+-+ EN +- |
+   |  |    | |     |  +-----+               +-----+   |     | |    |  |
+   |  +----+ |     |                                  |     | +----+  |
+   |         |     +----------------------------------+     |         |
+   +---------+                Core Network                  +---------+
+     Overlay                                                  Overlay
+     Network                                                  Network
+
+                        Legend:   EN  -  Edge Node
+                                  CN  -  Core Node
+
+                    Figure 1:  Overlay Reference Model
+
+   Figure 1 shows a reference network.  The core network is represented
+   by the large box in the center.  It contains five core-nodes marked
+   'CN'.  The four boxes around the edge marked "Overlay Network"
+   represent four islands of a single overlay network.  Only the nodes
+   of this network with TE links into the core network are shown.  These
+   nodes are called edge-nodes; the terminology is in respect to the
+   core network, not the overlay network.  Note that each box marked
+   "Overlay Network" could contain many other nodes.  Such nodes are not
+   shown; they do not participate directly in the signaling described in
+   this document.  Only the edge-nodes can signal to set up links across
+   the core to other edge-nodes.
+
+   How a link between edge-nodes is requested and triggered is out of
+   the scope of this document, as is precisely how that link is used by
+   the Overlay Network.  One possibility is that the edge-nodes will
+   inform the other nodes of the overlay network of the existence of the
+   link, possibly using a forwarding adjacency as described in
+   [MPLS-HIER].  Note that this contrasts with a forwarding adjacency
+   that is provided by the core network as a link between core-nodes.
+
+
+
+
+Swallow, et al.             Standards Track                     [Page 3]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   In the overlay model, there may be restrictions on what may be
+   signaled between an edge-node and a core-node.  This memo addresses
+   the application of GMPLS to the overlay model.  Specifically, it
+   addresses RSVP-TE procedures between an edge-node and a core-node in
+   the overlay model.  All signaling procedures are identical to the
+   GMPLS extensions specified in [RFC3473], except as noted in this
+   document.
+
+   This document primarily addresses interactions between an edge-node
+   and it's adjacent (at the data plane) core-node; out-of-band and
+   non-adjacent signaling capabilities may mean that signaling messages
+   are delivered on a longer path.  Except where noted, the term core-
+   node refers to the node immediately adjacent to an edge-node across a
+   particular data plane interface.  The term core-nodes, however,
+   refers to all nodes in the core.
+
+   Realization of a single or multiple instance of the UNI is
+   implementation dependent at both the CN and EN so long as it meets
+   the functional requirements for robustness, security, and privacy
+   detailed in Section 7.
+
+   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 [RFC2119].
+
+   Readers are assumed to be familiar with the terminology introduced in
+   [RFC3031], [GMPLS-ARCH], and [RFC3471].
+
+1.1.  GMPLS User-Network Interface (GMPLS UNI)
+
+   One can apply the GMPLS Overlay model at the User-Network Interface
+   (UNI) reference point defined in the Automatically Switched Optical
+   Network (ASON) [G.8080].  Consider the case where the 'Core Network'
+   in Figure 1 is a Service Provider network, and the Edge Nodes are
+   'user' devices.  The interface between an EN and a CN is the UNI
+   reference point, and to support the ASON model, one must define
+   signaling across the UNI.
+
+   The extensions described in this memo provide mechanisms for UNI
+   signaling that are compatible with GMPLS signaling [RFC3471,
+   RFC3473].  Moreover, these mechanisms for UNI signaling are in line
+   with the RSVP model; namely, there is a single end-to-end RSVP
+   session for the user connection.  The first and last hops constitute
+   the UNI, and the RSVP session carries the user parameters end-to-end.
+   This obviates the need to map (or carry) user parameters to (in) the
+   format expected by the network-to-network interface (NNI) used within
+   the Service Provider network.  This in turn means that the UNI and
+   NNI can be independent of one another, which is a requirement of the
+
+
+
+Swallow, et al.             Standards Track                     [Page 4]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   ASON architecture.  However, in the case that the UNI and NNI are
+   both GMPLS RSVP-based, the methodology specified in this memo allows
+   for a single RSVP session to instantiate both UNI and NNI signaling,
+   if so desired, and if allowed by Service Provider policy.
+
+2.  Addressing
+
+   Addresses for edge-nodes in the overlay model are drawn from the same
+   address space as the edge-nodes use to address their adjacent core-
+   nodes.  This may be the same address space as used by the core-nodes
+   to communicate among themselves, or it may be a VPN space supported
+   by the core-nodes as an overlay.
+
+   To be more specific, an edge-node and its attached core-node must
+   share the same address space that is used by GMPLS to signal between
+   the edge-nodes across the core network.  A set of <edge-node, core-
+   node> tuples share the same address space if the edge-nodes in the
+   set could establish LSPs (through the core-nodes) among themselves
+   without address mapping or translation (note that edge-nodes in the
+   set may be a subset of all the edge-nodes).  The address space used
+   by the core-nodes to communicate among themselves may, but need not,
+   be shared with the address space used by any of the <edge-node,
+   core-node> tuples.  This does not imply a mandatory 1:1 mapping
+   between a set of LSPs and a given addressing space.
+
+   When multiple overlay networks are supported by a single core
+   network, one or more address spaces may be used according to privacy
+   requirements.  This may be achieved without varying the core-node
+   addresses since it is the  <edge-node, core-node> tuple that
+   constitutes address space membership.
+
+   An edge-node is identified by either a single IP address representing
+   its Node-ID, or by one or more numbered TE links that connect the
+   edge-node to the core-nodes.  Core-nodes are assumed to be ignorant
+   of any other addresses associated with an edge-node (i.e., addresses
+   that are not used in signaling connections through the GMPLS core).
+
+   An edge-node need only know its own address, an address of the
+   adjacent core-node, and know (or be able to resolve) the address of
+   any other edge-node to which it wishes to connect, as well as (of
+   course) the addresses used in the overlay network island of which it
+   is a part.
+
+   A core-node need only know (and track) the addresses on interfaces
+   between that core-node and its attached edge-nodes, as well as the
+   Node IDs of those edge-nodes.  In addition, a core-node needs to know
+   the interface addresses and Node IDs of other edge-nodes to which an
+   attached edge-node is permitted to connect.
+
+
+
+Swallow, et al.             Standards Track                     [Page 5]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   When forming a SENDER_TEMPLATE, the ingress edge-node includes either
+   its Node-ID or the address of one of its numbered TE links.  In the
+   latter case the connection will only be made over this interface.
+
+   When forming a SESSION_OBJECT, the ingress edge-node includes either
+   the Node-ID of the egress edge-device or the address of one of the
+   egress' numbered TE links.  In the latter case the connection will
+   only be made over this interface.  The Extended_Tunnel_ID of the
+   SESSION Object is set to either zero or to an address of the ingress
+   edge-device.
+
+   Links may be either numbered or unnumbered.  Further, links may be
+   bundled or unbundled.  See [GMPLS-ARCH], [RFC3471], [BUNDLE], and
+   [RFC3477].
+
+3. ERO Processing
+
+   An edge-node MAY include an ERO.  A core-node MAY reject a Path
+   message that contains an ERO.  Such behavior is controlled by
+   (hopefully consistent) configuration.  If a core-node rejects a Path
+   message due to the presence of an ERO, it SHOULD return a PathErr
+   message with an error code of "Unknown object class" toward the
+   sender as described in [RFC3209].  This causes the path setup to
+   fail.
+
+   Further, a core-node MAY accept EROs that only include the ingress
+   edge-node, the ingress core-node, the egress core-node, and the
+   egress edge-node.  This is to support explicit label control on the
+   edge-node interface; see below.  If a core-node rejects a Path
+   message due to the presence of an ERO that is not of the permitted
+   format, it SHOULD return a PathErr message with an error code of Bad
+   Explicit Route Object as defined in [RFC3209].
+
+3.1. Path Message without ERO
+
+   When a core-node receives a Path message from an edge-node that
+   contains no ERO, it MUST calculate a route to the destination and
+   include that route in an ERO, before forwarding the PATH message.
+   One exception would be if the egress edge-node were also adjacent to
+   this core-node.  If no route can be found, the core-node SHOULD
+   return a PathErr message with an error code and value of 24,5 - "No
+   route available toward destination".
+
+3.2. Path Message with ERO
+
+   When a core-node receives a Path message from an edge-node that
+   contains an ERO, it SHOULD verify the route against its topology
+   database before forwarding the PATH message.  If the route is not
+
+
+
+Swallow, et al.             Standards Track                     [Page 6]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   viable (according to topology, currently available resources, or
+   local policy), then a PathErr message with an error code and value of
+   24,5 - "No route available toward destination" should be returned.
+
+3.3. Explicit Label Control
+
+   In order to support explicit label control and full identification of
+   the egress link, an ingress edge-node may include this information in
+   the ERO that it passes to its neighboring core-node.  In the case
+   that no other ERO is supplied, this explicit control information is
+   provided as the only hop of the ERO and is encoded by setting the
+   first subobject of the ERO to the node-ID of the egress core-node
+   with the L-bit set; following this subobject are all other subobjects
+   necessary to identify the link and labels as they would normally
+   appear.
+
+   The same rules apply to the presence of the explicit control
+   subobjects as the last hop in the ERO, if a fuller ERO is supplied by
+   the ingress edge-node to its neighbor core-node; but in this case the
+   L-bit MAY be clear.
+
+   This process is described in [RFC3473] and [EXPLICIT].
+
+4. RRO Processing
+
+   An edge-node MAY include an RRO.  A core-node MAY remove the RRO from
+   the Path message before forwarding it.  Further, the core-node may
+   remove the RRO from a Resv message before forwarding it to the edge-
+   node.  Such behavior is controlled by (hopefully consistent)
+   configuration.
+
+   Further, a core-node MAY edit the RRO in a Resv message such that it
+   includes only the subobjects from the egress core-node through the
+   egress edge-node.  This is to allow the ingress node to be aware of
+   the selected link and labels on at the far end of the connection.
+
+5. Notification
+
+   An edge-node MAY include a NOTIFY_REQUEST object in both the Path and
+   Resv messages it generates.  Core-nodes may send Notify messages to
+   edge-nodes that have included the NOTIFY_REQUEST object.
+
+   A core-node MAY remove a NOTIFY_REQUEST object from a Path or Resv
+   message received from an edge-node before forwarding it.
+
+   If no NOTIFY_REQUEST object is present in the Path or Resv received
+   from an edge-node, the core-node adjacent to the edge-node may
+   include a NOTIFY_REQUEST object and set its value to its own address.
+
+
+
+Swallow, et al.             Standards Track                     [Page 7]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   In either of the above cases, the core-node SHOULD NOT send Notify
+   messages to the edge-node.
+
+   When a core-node receives a NOTIFY_REQUEST object from an edge-node,
+   it MAY update the Notify Node Address with its own address before
+   forwarding it.  In this case, when Notify messages are received, they
+   MAY be selectively (based on local policy) forwarded to the edge-
+   node.
+
+6. Connection Deletion
+
+6.1. Alarm-Free Connection Deletion
+
+   RSVP-TE currently deletes connections using either a single pass
+   PathTear message, or a ResvTear and PathTear message combination.
+   Upon receipt of the PathTear message, a node deletes the connection
+   state and forwards the message.  In optical networks, however, it is
+   possible that the deletion of a connection (e.g., removal of the
+   cross-connect) in a node may cause the connection to be perceived as
+   failed in downstream nodes (e.g., loss of frame, loss of light,
+   etc.). This may in turn lead to management alarms and perhaps the
+   triggering of restoration/protection for the connection.
+
+   To address this issue, the graceful connection deletion procedure
+   SHOULD be followed.  Under this procedure, an ADMIN_STATUS object
+   MUST be sent in a Path or Resv message along the connection's path to
+   inform all nodes en route to the intended deletion, prior to the
+   actual deletion of the connection.  The procedure is described in
+   [RFC3473].
+
+   If an ingress core-node receives a PathTear without having first seen
+   an ADMIN_STATUS object informing it that the connection is about to
+   be deleted, it MAY pause the PathTear and first send a Path message
+   with an ADMIN_STATUS object to inform all downstream LSRs that the
+   connection is about to be deleted.  When the Resv is received echoing
+   the ADMIN_STATUS or using a timer as described in [RFC3473], the
+   ingress core-node MUST forward the PathTear.
+
+6.2. Connection Deletion with PathErr
+
+   [RFC3473] introduces the Path_State_Removed flag to a PathErr message
+   to indicate that the sender has removed all state associated with the
+   LSP and does not need to see a PathTear.  A core-node next to an
+   edge-node MAY map between teardown using ResvTear/PathTear and
+   PathErr with Path_state_Removed.
+
+
+
+
+
+
+Swallow, et al.             Standards Track                     [Page 8]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   A core-node next to an edge-node receiving a ResvTear from its
+   downstream neighbor MAY respond with a PathTear and send a PathErr
+   with Path_State_Removed further upstream.
+
+   Note, however, that a core-node next to an edge-node receiving a
+   PathErr with Path_State_Removed from its downstream neighbor MUST NOT
+   retain Path state and send a ResvTear further upstream because that
+   would imply that Path state further downstream had also been
+   retained.
+
+7. VPN Connections
+
+   As stated in the addressing section above, the extensions in this
+   document are designed to be compatible with the support of VPNs.
+   Since the core network may be some technology other than GMPLS, no
+   mandatory means of mapping core connections to access connections is
+   specified.  However, when GMPLS is used for the core network, it is
+   RECOMMENDED that the following procedure based on [MPLS-HIER] is
+   followed.
+
+   The VPN connection is modeled as being three hops.  One for each
+   access link and one hop across the core network.
+
+   The VPN connection is established using a two-step procedure.  When a
+   Path message is received at a core-node on an interface that is part
+   of a VPN, the Path message is held until a core connection is
+   established.
+
+   The connection across the core is setup as a separate signaling
+   exchange between the core-nodes, using the address space of the core
+   nodes.  While this exchange is in progress, the original Path message
+   is held at the ingress core-node.  Once the exchange for the core
+   connection is complete, this connection is used in the VPN connection
+   as if it were a single link.  This is signaled by including an IF_ID
+   RSVP_HOP object (defined in [RFC3473]) using the procedures defined
+   in [MPLS-HIER].
+
+   The original Path message is then forwarded within the VPN addressing
+   realm to the core-node attached to the destination edge-node.  Many
+   ways of accomplishing this are available, including IP and GRE
+   tunnels and BGP/MPLS VPNs.  Specifying a particular means is beyond
+   the scope of this document.
+
+
+
+
+
+
+
+
+
+Swallow, et al.             Standards Track                     [Page 9]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+8. Security Considerations
+
+   The trust model between the core and edge-nodes is different than the
+   one described in [RFC3473], as the core is permitted to hide its
+   topology from the edge-nodes, and the core is permitted to restrict
+   the actions of edge-nodes by filtering out specific RSVP objects.
+
+9. Acknowledgments
+
+   The authors would like to thank Kireeti Kompella, Jonathan Lang,
+   Dimitri Papadimitriou, Dimitrios Pendarakis, Bala Rajagopalan, and
+   Adrian Farrel for their comments and input.  Thanks for thorough
+   final reviews from Loa Andersson and Dimitri Papadimitriou.
+
+   Adrian Farrel edited the last two revisions of this document to
+   incorporate comments from Working Group last call and from AD review.
+
+10.  References
+
+10.1. Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
+                (GMPLS) Signaling Functional Description", RFC 3471,
+                January 2003.
+
+   [RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
+                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
+                Engineering (RSVP-TE) Extensions", RFC 3473, January
+                2003.
+
+   [RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                V., and G.  Swallow, "RSVP-TE: Extensions to RSVP for
+                LSP Tunnels", RFC 3209, December 2001.
+
+10.2. Informational References
+
+   [RFC3031]    Rosen, E., Viswanathan, A., and R.  Callon,
+                "Multiprotocol Label Switching Architecture", RFC 3031,
+                January 2001.
+
+   [RFC3477]    Kompella, K. and Y.  Rekhter, "Signalling Unnumbered
+                Links in Resource ReSerVation Protocol - Traffic
+                Engineering (RSVP-TE)", RFC 3477, January 2003.
+
+
+
+
+
+Swallow, et al.             Standards Track                    [Page 10]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+   [BUNDLE]     Kompella, K., Rekhter, Y., and Berger, L., "Link
+                Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
+                October 2005.
+
+   [EXPLICIT]   Berger, L., "GMPLS Signaling Procedure for Egress
+                Control", RFC 4003, February 2005.
+
+   [GMPLS-ARCH] Mannie, E., "Generalized Multi-Protocol Label Switching
+                (GMPLS) Architecture", RFC 3945, October 2004.
+
+   [MPLS-HIER]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+                Hierarchy with Generalized Multi-Protocol Label
+                Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
+                October 2005.
+
+   [G.8080]     ITU-T Rec.  G.8080/Y.1304, "Architecture for the
+                Automatically Switched Optical Network (ASON)," November
+                2001 (and Revision, January 2003).  For information on
+                the availability of this document, please see
+                http://www.itu.int.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swallow, et al.             Standards Track                    [Page 11]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+Authors' Addresses
+
+   George Swallow
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave,
+   Boxborough, MA 01719
+
+   Phone: +1 978 936 1398
+   EMail: swallow@cisco.com
+
+
+   John Drake
+   Boeing Satellite Systems
+   2300 East Imperial Highway
+   El Segundo, CA 90245
+
+   Phone: +1 412 370-3108
+   EMail: John.E.Drake2@boeing.com
+
+
+   Hirokazu Ishimatsu
+   G1M Co., Ltd.
+   Nishinippori Start up Office 214,
+   5-37-5 Nishinippori, Arakawaku,
+   Tokyo 116-0013, Japan
+
+   Phone: +81 3 3891 8320
+   EMail: hirokazu.ishimatsu@g1m.jp
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Swallow, et al.             Standards Track                    [Page 12]
+
+RFC 4208         RSVP-TE Support for the Overlay Model      October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Swallow, et al.             Standards Track                    [Page 13]
+