idnits 2.17.1 draft-malis-pwe3-cell-transport-00.txt: -(79): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ATM-ENCAPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 19 looks like a reference -- Missing reference section? 'ATM-ENCAPS' on line 39 looks like a reference -- Missing reference section? '2' on line 46 looks like a reference -- Missing reference section? '3' on line 91 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group 3 Internet Draft A. Malis 4 draft-malis-pwe3-cell-transport-00.txt Vivace Networks, Inc. 5 Expires: April 2003 L. Martini 6 Level 3 Communications 7 J. Brayley 8 Laurel Networks, Inc. 9 T. Walsh 10 Lucent Technologies 11 October 2002 13 PWE3 ATM Transparent Cell Transport Service 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The document describes a transparent cell transport service that 38 makes use of the "N-to-one" cell relay mode for PWE3 ATM cell 39 encapsulation described in [ATM-ENCAPS]. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC-2119 [2]. 47 PWE3 ATM Transparent Cell Transport Service October 2002 49 Table of Contents 51 1. Introduction...................................................2 52 2. Transparent Cell Transport Definition..........................2 53 Security Considerations...........................................2 54 References........................................................3 55 Acknowledgments...................................................3 56 Author's Addresses................................................3 58 1. Introduction 60 This transparent cell transport service allows migration of ATM 61 services to a PSN without having to provision the ATM subscriber or 62 customer edge (CE) devices. The ATM CEs will view the ATM 63 transparent cell transport service as if they were directly connected 64 via a TDM leased line. This service is most likely to be used as an 65 internal function in a ATM service provider's network as a way to 66 connect existing ATM switches via a higher speed PSN, or to provide 67 ATM "backhaul" services for remote access to existing ATM networks. 69 2. Transparent Cell Transport Definition 71 The transparent port service is a natural application of the "N-to- 72 one� cell relay mode for PWE3 ATM encapsulation described in [3]. 74 The ATM transparent port service emulates connectivity between two 75 remote ATM ports. This service is useful when one desires to connect 76 two CEs without processing or switching at the VPC or VCC layer. The 77 ingress PE discards any idle/unassigned cells received from the 78 ingress ATM port, and maps all other received cells to a single 79 Pseudo Wire, using the �N-to-one� cell relay encapsulation in [3]. 81 The egress PE doesn�t change the VPI, VCI, PTI, or CLP bits when it 82 sends these cells on the egress ATM port. Therefore the transparent 83 port service appears to emulate an ATM transmission convergence layer 84 connection between two ports. However, since the ingress PE discards 85 idle/unassigned cells, this service benefits from statistical 86 multiplexing. 88 3. Security Considerations 90 This draft does not introduce any new security considerations beyond 91 those in [3]. 93 PWE3 ATM Transparent Cell Transport Service October 2002 95 4. References 97 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 98 9, RFC 2026, October 1996. 100 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 101 Levels", BCP 14, RFC 2119, March 1997 103 3 Martini, L., et al, "Encapsulation Methods for Transport of ATM 104 Cells/Frame Over IP and MPLS Networks", work in progress, draft- 105 ietf-pwe3-atm-encap-00.txt, October 2002 107 Acknowledgments 109 The authors would like to thank the members of the PWE3 working group 110 for their assistance on this draft. 112 Author's Addresses 114 Andrew G. Malis 115 Vivace Networks, Inc. 116 2730 Orchard Parkway 117 San Jose, CA 95134 118 Email: Andy.Malis@vivacenetworks.com 120 Luca Martini 121 Level 3 Communications, LLC. 122 1025 Eldorado Blvd. 123 Broomfield, CO, 80021 124 Email: luca@level3.net 126 Jeremy Brayley 127 Laurel Networks, Inc. 128 1300 Omega Drive 129 Pittsburgh, PA 15205 130 Email: jbrayley@laurelnetworks.com 132 Tom Walsh 133 Lucent Technologies 134 1 Robbins Road 135 Westford, MA 01886 USA 136 Email: tdwalsh@lucent.com