doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3308.txt b/doc/rfc/rfc3308.txt
new file mode 100644
index 0000000..7227676
--- /dev/null
+++ b/doc/rfc/rfc3308.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         P. Calhoun
+Request for Comments: 3308                          Black Storm Networks
+Category: Standards Track                                         W. Luo
+                                                     Cisco Systems, Inc.
+                                                            D. McPherson
+                                                                     TCB
+                                                               K. Peirce
+                                                   Malibu Networks, Inc.
+                                                          November 2002
+
+
+                  Layer Two Tunneling Protocol (L2TP)
+                   Differentiated Services Extension
+
+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 (2002).  All Rights Reserved.
+
+Abstract
+
+   This document describes mechanisms which enable the Layer Two
+   Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB)
+   code for the L2TP control connection, as well as individual sessions
+   within an L2TP tunnel.
+
+   L2TP provides a standard method for tunneling PPP packets.  The
+   current specification provides no provisions for supporting
+   Differentiated Services (diffserv) over the L2TP control connection
+   or subsequent data sessions.  As a result, no standard mechanism
+   currently exists within L2TP to provide L2TP protocol negotiations
+   for service discrimination.
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 1]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+Table of Contents
+
+   1.   Specification of Requirements ...............................  2
+   2.   Introduction ................................................  2
+   3.   Control Connection Operation ................................  3
+   3.1. Control Connection DS AVP (SCCRQ, SCCRP) ....................  4
+   4.   Session Operation ...........................................  4
+   4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) .....................  6
+   5.   DS AVPs Correlation .........................................  6
+   6.   PHB Encoding ................................................  6
+   7.   DSCP Selection ..............................................  7
+   8.   Packet Reordering and Sequence Numbers ......................  7
+   9.   Crossing Differentiated Services Boundaries .................  7
+   10.  IANA Considerations .........................................  8
+   11.  Security Considerations .....................................  8
+   12.  Acknowledgements ............................................  8
+   13.  References ..................................................  8
+   14.  Authors' Addresses ..........................................  9
+   15.  Full Copyright Statement .................................... 10
+
+1. Specification of Requirements
+
+   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. Introduction
+
+   The L2TP specification currently provides no mechanism for supporting
+   diffserv (DS).  This document describes mechanisms that enable L2TP
+   to indicate desired PHB code, as defined in [RFC 3140], to be
+   associated with an L2TP control connection, as well as individual
+   sessions within an L2TP tunnel.
+
+   The actual bit interpretation of the DS field is beyond the scope of
+   this document, and is purposefully omitted.  This document is
+   concerned only with defining a uniform exchange and subsequent
+   mapping mechanism for the DS AVPs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 2]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+3. Control Connection Operation
+
+   As defined in [RFC 2661], a control connection operates in-band over
+   a tunnel to control the establishment, release, and maintenance of
+   sessions and of the tunnel itself.  As such, this document provides a
+   mechanism to enable discrimination of L2TP control messages from
+   other packets.  For this purpose, we introduce the Control Connection
+   DS (CCDS) AVP.
+
+   The presence of the CCDS AVP serves as an indication to the peer (LAC
+   or LNS) that the tunnel initiator wishes both the tunnel initiator
+   and terminator to use the per-hop behavior(s) (PHB(s)) indicated by
+   the AVP's PHB code for all packets within the tunnel's control
+   connection.  A PHB is a description of the externally observable
+   forwarding behavior of a DS node applied to a particular DS behavior
+   aggregate, as defined in [RFC 2475].  The most simple example of a
+   PHB is one which guarantees a minimal bandwidth allocation of a link
+   to a behavior aggregate.
+
+   Upon receipt of a Start-Control-Connection-Request (SCCRQ) containing
+   the CCDS AVP, if the tunnel terminator provides no support for the
+   CCDS AVP it MUST ignore the AVP and send an SCCRP to the tunnel
+   initiator without the CCDS AVP.  The tunnel initiator interprets the
+   absence of the CCDS AVP in the SCCRP as an indication that the tunnel
+   terminator is incapable of supporting CCDS.
+
+   Upon receipt of an SCCRP that contains no CCDS AVP in response to a
+   SCCRQ that contained a CCDS AVP, if the tunnel initiator wants to
+   continue tunnel establishment it sends an SCCCN.  Otherwise, it sends
+   a StopCCN to the tunnel terminator to end the connection.  The
+   StopCCN control message MUST contain the Result Code 8 that indicates
+   CCDS AVP value (47) as the reason for sending the StopCCN.
+
+   If the tunnel terminator provides support for CCDS, it SHOULD use the
+   Host Name AVP embedded in SCCRQ to consult its local policy, and to
+   determine whether local policy permits the requested PHB code to be
+   used on this control connection.  If it is unwilling or unable to
+   support the requested PHB code after consulting the local policy, the
+   tunnel terminator MUST send an SCCRP control message containing a
+   CCDS AVP indicating the value it is willing to use.  If the CCDS AVP
+   value is the same as the one in the SCCRQ, it signals the acceptance
+   of the requested PHB code.  If the value is different it serves as a
+   counter-offer by the tunnel terminator.
+
+
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 3]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+   If the tunnel initiator receives an SCCRP that contains a CCDS AVP
+   with a value other than that requested in the SCCRQ, the tunnel
+   initiator SHOULD check the PHB code against its own policy.  If it is
+   unwilling to use the value, the tunnel initiator MUST send a StopCCN
+   control message containing the Result Code 8 that indicates CCDS AVP
+   value (47) as the reason for sending the StopCCN.
+
+3.1. Control Connection DS AVP (SCCRQ, SCCRP)
+
+   The CCDS AVP is encoded as Vendor ID 0, and the Attribute Type is 47.
+
+   Each CCDS AVP is encoded as follows:
+
+     Vendor ID = 0
+     Attribute = 47
+
+    0                   1                   2                   3
+    0 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|H|0|0|0|0|    Length         |              0                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              47               |           PHB Code            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This AVP MAY be present in the following message types:  SCCRQ and
+   SCCRP.  This AVP MAY be hidden (the H-bit set to 0 or 1) and is
+   optional (M-bit not set).  The length (before hiding) of this AVP
+   MUST be 8 octets.  The encoding of the PHB code is described in
+   Section 6.
+
+4. Session Operation
+
+   As defined in [RFC 2661], an L2TP session is connection-oriented. The
+   LAC and LNS maintain states for each call that is initiated or
+   answered by an LAC.  An L2TP session is created between the LAC and
+   LNS when an end-to-end connection is established between a Remote
+   System and the LNS.  Datagrams related to the connection are sent
+   over the tunnel between the LAC and LNS.  As such, this document
+   provides a mechanism to enable discrimination for packets within a
+   particular session from those in other sessions.  For this purpose,
+   we introduce the Session DS (SDS) AVP.
+
+   The presence of the SDS AVP serves as an indication to the peer (LAC
+   or LNS) that the session initiator wishes both the session initiator
+   and terminator to use the per-hop behavior(s) (PHB(s)) indicated by
+   the AVP's PHB code for all packets within the session.
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 4]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+   Upon receipt of an Incoming-Call-Request (ICRQ) or Outgoing-Call-
+   Request (OCRQ) containing the SDS AVP if the session terminator
+   provides no support for the requested PHB code, the session
+   terminator MUST ignore the SDS AVP and send an ICRP or OCRP to the
+   session initiator without the SDS AVP.  The session initiator
+   interprets the absence of the SDS AVP in the ICRP or OCRP as an
+   indication that the session terminator is incapable of supporting
+   SDS.
+
+   Upon receipt of an ICRP or OCRP that contains no SDS AVP in response
+   to an ICRQ or OCRQ that contained an SDS AVP, if the session
+   initiator is willing to omit employing SDS AVP it continues session
+   establishment as defined in [RFC 2661].  Otherwise, it sends a CDN to
+   the session terminator to end the connection.  The CDN control
+   message MUST contain the Result Code 12 that indicates SDS AVP value
+   (48) as the reason for sending the CDN.
+
+   In order to help the session terminator to distinguish one session
+   from another when consulting the local policy of the PHB code, the
+   session initiator MAY use the identifier or a combination of
+   identifiers embedded in AVPs such as Proxy Authen Name AVP, Calling
+   Number AVP, Called Number AVP, and Sub-Address AVP.  When Proxy
+   Authen Name AVP is used as a distinguishor, it SHOULD be present in
+   the ICRQ or OCRQ.  The designated DS identifier(s) used for looking
+   up the PHB code SHOULD be configurable.
+
+   If the session terminator provides support for SDS, it SHOULD use the
+   the designated DS identification AVP (via out-of-band agreement
+   between the administrators of the LAC and LNS) to consult the local
+   policy and determinate whether the local policy permits the requested
+   PHB code to be used on this session.  If it is unwilling or unable to
+   support the requested PHB code the session terminator MUST do one of
+   the following:
+
+   1) Send a CDN message containing the Result Code 12 that indicates
+      SDS AVP value (48) as the reason for sending the CDN.
+
+   2) Send an Incoming-Call-Reply (ICRP) or Outgoing-Call-Reply (OCRP)
+      message containing an SDS AVP indicating the PHB code the
+      terminator is willing to use for the session.
+
+   If the session terminator supports the PHB code in the SDS AVP
+   session establishment MUST continue as defined in [RFC 2661].
+
+   If the session initiator receives an ICRP or OCRP that contains an
+   SDS AVP with a value other than that requested in the ICRQ or OCRQ,
+   and the session initiator is unwilling to use the value, the session
+   initiator MUST send a CDN message containing the Result Code 12 that
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 5]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+   indicates SDS AVP value (48) as the reason for sending the CDN.  If
+   the session initiator receives an ICRP or OCRP that contains an SDS
+   AVP with a value other than that requested in the ICRQ or OCRQ, and
+   the session initiator is willing to use the value, the session
+   initiator MUST proceed as indicated in [RFC 2661].
+
+4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP)
+
+   The SDS AVP is encoded as Vendor ID 0, and the Attribute Value is 48.
+
+   Each SDS AVP is encoded as follows:
+
+     Vendor ID = 0
+     Attribute = 48
+
+    0                   1                   2                   3
+    0 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|H|0|0|0|0|    Length         |              0                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              48               |           PHB Code            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This AVP MAY be present in the following message types:  ICRQ, ICRP,
+   OCRQ and OCRP.  This AVP MAY be hidden (the H-bit set to 0 or 1) and
+   is optional (M-bit is not set 0).  The length (before hiding) of this
+   AVP MUST be 8 octets.  The encoding of the PHB code is described in
+   Section 6.
+
+5. DS AVPs Correlation
+
+   CCDS AVP and SDS AVP are independent of each other.  CCDS AVP is used
+   to signal diffserv for the control connection between two L2TP peers,
+   while SDS AVP is used for data connection.  The PHB code signaled in
+   one AVP SHOULD NOT have any implication on the PHB code signaled in
+   the other AVP.  Implementations MAY choose to implement either or
+   both DS AVPs, and operations MAY choose to enable diffserv on either
+   or both types of connections.
+
+6. PHB Encoding
+
+   The PHB code is a left-justified 16-bit field using Per Hop Behavior
+   (PHB) encoding defined in [RFC 3140].  Note that [RFC 3140] and its
+   successor are the ultimate authority defining PHB encoding.
+
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 6]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+   Upon successful establishment of an L2TP tunnel control connection or
+   individual L2TP session employing the appropriate DS AVP defined in
+   this document, both LAC and LNS MUST use their own PHB-to-DSCP
+   mappings of their present DS domains to map the PHB to a DSCP and
+   place it in the DS field of the outer IP header of packets
+   transmitted on the connection.
+
+7. DSCP Selection
+
+   The requirements or rules of each service and DSCP mapping are set
+   through administrative policy mechanisms which are outside the scope
+   of this document.
+
+8. Packet Reordering and Sequence Numbers
+
+   [RFC 2474] RECOMMENDS that PHB implementations not cause reordering
+   of packets within an individual connection.  [RFC 3140] requires that
+   a set of PHBs signaled using a single PHB ID MUST NOT cause
+   additional packet reordering within an individual connection vs.
+   using a single PHB.  Since the CCDS and SDS AVPs contain one PHB ID,
+   use of diffserv PHBs in accordance with this specification should not
+   cause additional packet reordering within an L2TP control or data
+   connection.
+
+   Sequence numbers are required to be present in all control messages
+   and are used to provide reliable delivery on the control connection,
+   as defined in [RFC 2661].  While packet reordering is inevitably as
+   much a function of the network as it is local traffic conditioning,
+   the probability of it occurring when employing the CCDS AVP is same
+   as when not employing the AVP.  Data messages MAY use sequence
+   numbers to reorder packets and detect lost packets.
+
+9. Crossing Differentiated Services Boundaries
+
+   With the potential that an L2TP connection traverses an arbitrary
+   number of DS domains, signaling PHBs via L2TP is more appropriate
+   than signaling DSCPs, because it maintains a consistent end-to-end
+   differentiated service for the L2TP connection.  As per [RFC 2983],
+   the negotiated PHBs are mapped to locally defined DSCPs of the
+   current DS domain at the tunnel ingress node.  At the DS domain
+   boundary nodes, the DSCPs can be rewritten in the DS field of the
+   outer IP header, so that the DSCPs are always with respect to
+   whatever DS domain the packet happens to be in.
+
+   As a result, it is perfectly acceptable that the outermost DS field
+   of packets arriving on a given control connection or session are not
+   marked with the same DSCP value that was used by the tunnel ingress
+   node.
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 7]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+10. IANA Considerations
+
+   This document defines 2 L2TP Differentiated Services Extension AVPs.
+   The IANA has assigned the value of 47 for the "CCDS AVP" defined in
+   section 5.1 and the value of 48 for SDS AVP defined in section 6.1.
+
+   IANA has also assigned L2TP Result Code values of 8 for disconnecting
+   control connection due to mismatching CCDS value (StopCCN), and 12
+   for disconnecting call due to mismatching SDS value (CDN).
+
+11. Security Considerations
+
+   This encoding in itself raises no security issues.  However, users of
+   this encoding should consider that modifying a DSCP MAY constitute
+   theft or denial of service, so protocols using this encoding MUST be
+   adequately protected.  No new security issues beyond those discussed
+   in [RFC 2474] and [RFC 2475] are introduced here.
+
+12. Acknowledgements
+
+   Many thanks to David Black, W. Mark Townsley, Nishit Vasavada, Andy
+   Koscinski and John Shriver for their review and insightful feedback.
+
+13. References
+
+   [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
+              RFC 1661, July 1994.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black "Definition
+              of the Differentiated Services Field (DS Field) in the
+              IPv4 and IPv6 Headers", RFC 2474, December 1998.
+
+   [RFC 2475] Blake, S., Black, D., Carlson, Z., Davies, E., Wang, Z.
+              and W. Weiss, "An Architecture for Differentiated
+              Services", RFC 2475, December 1998.
+
+   [RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
+              and B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661,
+              August 1999.
+
+   [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
+              2983, October 2000.
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 8]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+   [RFC 3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
+              "Per Hop Behavior Identification Codes", RFC 3140, June
+              2001.
+
+14. Authors' Addresses
+
+   Pat R. Calhoun
+   110 Nortech Parkway
+   San Jose, CA 95134-2307
+
+   Phone: +1 408.941.0500
+   EMail: pcalhoun@bstormnetworks.com
+
+
+   Wei Luo
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   Phone: +1 408.525.6906
+   EMail: luo@cisco.com
+
+
+   Danny McPherson
+   TCB
+
+   Phone: +1 303.470.9257
+   EMail: danny@tcb.net
+
+
+   Ken Peirce
+   Malibu Networks, Inc.
+   1107 Investment Blvd, Suite 250
+   El Dorado Hills, CA 95762
+
+   Phone: +1 916.941.8814
+   EMail: Ken@malibunetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                     [Page 9]
+
+RFC 3308                L2TP Diffserv Extension            November 2002
+
+
+15. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun, et. al.            Standards Track                    [Page 10]
+