doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc4816.txt b/doc/rfc/rfc4816.txt
new file mode 100644
index 0000000..b7ddae7
--- /dev/null
+++ b/doc/rfc/rfc4816.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          A. Malis
+Request for Comments: 4816                                      Verizon
+Category: Standards Track                                    L. Martini
+                                                          Cisco Systems
+                                                             J. Brayley
+                                                            ECI Telecom
+                                                               T. Walsh
+                                                       Juniper Networks
+                                                          February 2007
+
+
+               Pseudowire Emulation Edge-to-Edge (PWE3)
+  Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service
+
+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 IETF Trust (2007).
+
+Abstract
+
+   The document describes a transparent cell transport service that
+   makes use of the "N-to-one" cell relay mode for Pseudowire Emulation
+   Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell
+   encapsulation.
+
+1.  Introduction
+
+   This transparent cell transport service allows migration of ATM
+   services to a PSN without having to provision the ATM subscriber or
+   customer edge (CE) devices.  The ATM CEs will view the ATM
+   transparent cell transport service as if they were directly connected
+   via a Time Division Multiplexer (TDM) leased line.  This service is
+   most likely to be used as an internal function in an ATM service
+   provider's network as a way to connect existing ATM switches via a
+   higher-speed PSN, or to provide ATM "backhaul" services for remote
+   access to existing ATM networks.
+
+
+
+
+
+
+
+Malis, et al.               Standards Track                     [Page 1]
+
+RFC 4816      PWE3 ATM Transparent Cell Transport Service  February 2007
+
+
+1.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 [1].
+
+2.  Transparent Cell Transport Definition
+
+   The transparent port service is a natural application of the "N-to-
+   one" Virtual Circuit Connection (VCC) cell transport mode for PWE3
+   ATM encapsulation described in [2], and MUST be used with pseudowires
+   of type 0x0003, "ATM transparent cell transport" [4].
+
+   The ATM transparent port service emulates connectivity between two
+   remote ATM ports.  This service is useful when one desires to connect
+   two CEs without processing or switching at the Virtual Path
+   Connection (VPC) or VCC layer.  The ingress PE discards any
+   idle/unassigned cells received from the ingress ATM port, and maps
+   all other received cells to a single pseudowire.
+
+   The egress PE does not change the Virtual Path Identifier (VPI),
+   Virtual Circuit Identifier (VCI), Payload Type Identifier (PTI), or
+   Cell Loss Priority (CLP) bits when it sends these cells on the egress
+   ATM port.  Therefore, the transparent port service appears to emulate
+   an ATM transmission convergence layer connection between two ports.
+   However, since the ingress PE discards idle/unassigned cells, this
+   service benefits from statistical multiplexing bandwidth savings.
+
+   In accordance with [2], cell concatenation MAY be used for
+   transparent cell-relay transport in order to save the PSN bandwidth.
+   If used, it MUST be agreed between the ingress and egress PEs.  In
+   particular, if the Pseudo Wire has been set up using the PWE3 control
+   protocol [3], the ingress PE MUST NOT exceed the value of the
+   "Maximum Number of concatenated ATM cells" Pseudowire Interface
+   Parameter Sub-TLV (Interface Parameter ID = 0x02 [4]) received in the
+   Label Mapping message for the Pseudo Wire, and MUST NOT use cell
+   concatenation if this parameter has been omitted by the egress PE.
+
+   ATM Operations and Management (OAM) cells MUST be transported
+   transparently, and the PEs do not act on them.  If the PEs detect a
+   PSN or pseudowire failure between them, they do not generate any OAM
+   cells, but rather bring down the ATM interfaces to the CEs (e.g.,
+   generating LOS on the ATM port), just as if it were a transmission
+   layer failure.
+
+
+
+
+
+
+
+Malis, et al.               Standards Track                     [Page 2]
+
+RFC 4816      PWE3 ATM Transparent Cell Transport Service  February 2007
+
+
+   Similarly, ATM Integrated Local Management Interface (ILMI) signaling
+   from the CEs, if any, MUST be transported transparently, and the PEs
+   do not act on it.  However, the PEs must act on physical interface
+   failure by either withdrawing the PW labels or by using pseudowire
+   status signaling to indicate the interface failure.  The procedures
+   for both alternatives are described in [3].
+
+3.  Security Considerations
+
+   This document does not introduce any new security considerations
+   beyond those in [2] and [3].  This document defines an application
+   that utilizes the encapsulation specified in [2], and does not
+   specify the protocols used to carry the encapsulated packets across
+   the PSN.  Each such protocol may have its own set of security issues,
+   but those issues are not affected by the application specified
+   herein.  Note that the security of the transported ATM service will
+   only be as good as the security of the PSN.  This level of security
+   might be less rigorous than a native ATM service.
+
+4.  Congestion Control
+
+   Since this document discusses an application of the "N-to-one" VCC
+   cell transport mode for PWE3 ATM encapsulation described in [2], the
+   congestion control considerations are identical to those discussed in
+   section 15 of [2].  The PWE3 Working Group is also undertaking
+   additional work on ATM-related congestion issues, and implementers
+   should anticipate that an RFC will be published describing additional
+   congestion control techniques that should be applied to ATM emulation
+   over pseudowires.
+
+5.  Normative References
+
+   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [2] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J.,
+       and G. Koleyni, "Encapsulation Methods for Transport of
+       Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717,
+       December 2006.
+
+   [3] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron,
+       "Pseudowire Setup and Maintenance Using the Label Distribution
+       Protocol (LDP)", RFC 4447, April 2006.
+
+   [4] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+       Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+
+
+
+
+Malis, et al.               Standards Track                     [Page 3]
+
+RFC 4816      PWE3 ATM Transparent Cell Transport Service  February 2007
+
+
+Acknowledgments
+
+   The authors would like to thank the members of the PWE3 working group
+   for their assistance on this document, and Sasha Vainshtein of Axerra
+   in particular for his comments and suggestions.
+
+Author's Addresses
+
+   Andrew G. Malis
+   Verizon Communications
+   40 Sylvan Road
+   Waltham, MA
+
+   EMail: andrew.g.malis@verizon.com
+
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+   Jeremy Brayley
+   ECI Telecom
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+
+   EMail: jeremy.brayley@ecitele.com
+
+
+   Tom Walsh
+   Juniper Networks
+   1194 N Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: twalsh@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al.               Standards Track                     [Page 4]
+
+RFC 4816      PWE3 ATM Transparent Cell Transport Service  February 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+Malis, et al.               Standards Track                     [Page 5]
+