Internet Draft E. McCoy Document: draft-mccoy-pppext-pppoephy-00.txt J. Sauer Category: Informational Tellabs Expiration Date: August 2002 February 2002 PPP over Full Duplex Point-to-Point Ethernet Physical Layers draft-mccoy-pppext-pppoephy-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026[1]. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document provides a definition for encapsulating the PPP protocol directly on the various full duplex point-to-point Ethernet physical layers. The later includes transmission bit rates of 10Mbps, 100Mbps, 1Gbps, and 10Gbps. Note this is a distinct protocol from PPPoE, as the Ethernet frame is not existent here. All PPP packet semantics and syntax are retained. The proposed methods in this document may be especially useful for low cost, high bandwidth physical channel implementations. In particular it specifies and redefines all necessary Ethernet Medium Independent Interface functional "clauses." 2. Conventions used in this document 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]. 3. Introduction McCoy Expires August 2001 1 draft-mccoy-pppext-pppoephy-00.txt February 2002 This document proposes a simplified Physical Layer for the Internet. The rational is to simplify and reduce the cost of Internet packet switching infrastructure, consistent with these architectural principles found in the Internet Architecture Board`s RFC 1958 [3]: "3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. 3.3 All designs must scale readily to very many nodes per site and to many millions of sites. 3.4 Performance and cost must be considered as well as functionality. 3.5 Keep it simple. When in doubt during design, choose the simplest solution. 4.1 Avoid any design that requires addresses to be hard coded or stored on non-volatile storage (except of course where this is an essential requirement as in a name server or configuration server). In general, user applications should use names rather than addresses." The authors firmly believe that these architectural characteristics have served the Internet community extremely well, and indeed, are the fundamental reason for the Internet`s great success. However, the authors also believe that unnecessary complexity has been introduced that have moved away from these principles. See [4] for a discussion of the larger issues involved. One issue is the lack of explicit "Internet" Layer 1, physical channels. By historically not defining an Internet physical layer, many link technologies have been defined. This is in itself good, however they have also defined packet switching capability "under" IP as well. Examples are all the switched Layer 2 Ethernet LAN technologies. Even the latest of these, ANSI`s Generic Framing Procedure [5], has an optional packet switching capability. However, the Internet/IETF community has defined a non-switched Layer 2 interface, namely PPP [6]. This protocol provides link management and layer 1 encapsulation procedures, essential to logically distinguish these functions from the Layer 3 functions of IP. Consequently, in an IP context, we often informally say "packet over SONET" when one actually means IP/PPP over SONET (or whatever). Note that PPP is not considered "sub IP" in the usual sense. McCoy Expires August 2001 2 draft-mccoy-pppext-pppoephy-00.txt February 2002 Thus by not defining an Internet physical layer, IP (or IP/PPP) is often encapsulated in some other packet switching protocol, leaving the unwarranted and unintended impression that IP "needs" some other switching capability. There also has been the impression that IP is somehow insufficient, or even "broken", for actual common carrier service provisioning. The authors believe, consistent with the architectural principles of RFC 1985 enumerated above, that a definition of "PPP over Ethernet Layer 1" is mandated. Driving this conclusion is the current network implementation economics, namely a need for a lower cost interface structure. 4. Terminology ANSI - American National Standards Institute AUI - Attachment Unit Interface EIA/TIA - Electronic/Telecommunication Industry Association GMII - Gigabit MII MAC - Medium Access Control MLPPP - Multi Link PPP MMF - Multi Mode Fiber MMI - Medium-Independent Interface PCS - Physical Coding Sublayer PLS - Physical Layer Signaling PMA - Physical Medium Sublayer PPP - Point to Point Protocol PPPoE - PPP over Ethernet RPR - Resilient Packet Ring RS - Reconciliation Sublayer SDH - Synchronous Digital Hierarchy SMF - Single Mode Fiber SONET - Synchronous Optical Network STP - Shielded Twisted Pair TDM - Time Division Multiplexing UTP - Unshielded Twisted Pair WIS - Wide Area Network Interface Sub-layer XAUI - Extended AUI XGMII - Extended GMII XGXS - XGMII Extender Sublayer 5. Overview of the Issues The dominant cost associated with a data network is that of its constituent physical interfaces. In particular the wide area network (WAN) digital hierarchies, for example SONET and SDH, are designed for high bit-rate TDM sub-channel time slot cross- connection, a difficult task requiring extremely precise externally- provided timing. Consequently such interfaces are necessarily expensive. McCoy Expires August 2001 3 draft-mccoy-pppext-pppoephy-00.txt February 2002 PPP is currently defined for SONET/SDH encapsulation [7], as well as other physical layers. In addition, methods are defined to encapsulate PPP into still other packet switching protocols, such as Ethernet [8], RPR [9], Frame Relay [10], ATM [11], etc. The former two are likely to be widely implemented. Compared to a PPP over SONET interface, an Ethernet layer 1 physical interface is much less costly, as the packet switch terminates the physical layer, obviating the need for externally-provided precision timing and other costly complexities. The disadvantage is that the delay experienced in a packet switch is necessarily higher and more variable than in a TDM cross-connect. Consequently the use of Ethernet physical layer interfaces is attractive, but Ethernet (and its variations like RPR [12]) also are essentially redundant packet switching technologies. Thus a service provider ends up implementing and managing both IP and Ethernet/RPR switching capabilities. This duplicated capability violates the enumerated Internet IAB architecture principles, and can only add complexity and cost into a network service offering. Clearly only a single packet switching technology is sufficient, by definition. Only trivial semantics distinguish IP and Ethernet/RPR switching protocols, and only IP is known to scale. This places the data service industry in a dilemma, namely wishing the less costly physical interface of Ethernet layer 1, but not actually needing or wanting Ethernet`s redundant layer 2 packet switching capability, scaling problems, etc. One solution, already underway, is to define "PPPoE", "PPPoRPR", as well as some day defining "PPPoGFP", "PPPoMPLS", etc., as stated above. However this increases complexities and costs rather than simplifying operations and reducing cost. Alternatively, and proposed here, is to retain Ethernet`s full duplex point-to-point physical interface alternatives, but define PPP encapsulation directly - leaving out the redundant MAC frame and hence all Ethernet Layer 2 functionality. The authors believe this is the best of both worlds, and consistent with the Internet`s proven architectural principles. 5.1 Overview of PPP For completeness here is a summarization of the overall structure of PPP. The best way to accomplish this is to literally quote the following four paragraphs from RFC 1474 [13]: "The PPP is not one single protocol but a large family of protocols. Each of these is, in itself, a fairly complex protocol. The PPP protocols may be divided into three rough categories: McCoy Expires August 2001 4 draft-mccoy-pppext-pppoephy-00.txt February 2002 Control Protocols The Control Protocols are used to control the operation of the PPP. The Control Protocols include the Link Control Protocol(LCP), the Password Authentication Protocol (PAP), the Link Quality Report (LQR), and the Challenge Handshake Authentication Protocol (CHAP). Network Protocols The Network Protocols are used to move the network traffic over the PPP interface. A Network Protocol encapsulates the datagrams of a specific higher-layer protocol that is using the PPP as a data link. Note that within the context of PPP, the term `Network Protocol` does not imply an OSI Layer-3 protocol; for instance, there is a Bridging network protocol. Network Control Protocols (NCPs) The NCPs are used to control the operation of the Network Protocols. Generally, each Network Protocol has its own Network Control Protocol; thus, the IP Network Protocol has its IP ControlProtocol, the Bridging Network Protocol has its Bridging Network Control Protocol and so on." Note all of this protocol family use the same physical layer encapsulation; hence our proposed "PPP over Ethernet Layer 1" applies to the entire PPP family of protocols. MultiLink PPP (MLPPP) is mentioned for completeness [14]. This protocol is an extension to PPP allowing for a "bundle" of physical links, implementing inverse multiplexing. Note IP would then see a single link at layer 3, but that link would really be multiple physical links. MLPPP employs the same packet encapsulation technology, as does ordinary PPP, so the protocol proposed here applies to both PPP and MLPPP. PPP multiplexing capabilities as described in [15] would also apply. 5.2 PPP Layer 1 Encapsulation PPP layer 1 encapsulation is reviewed for completeness. PPP operation on "slow" asynchronous links is very similar to historic Ethernet, with "start bits" and "stop bits" encapsulating each byte of the PPP frame, with no signal power otherwise. This is not relevant to our purpose. However, "synchronous PPP" uses "HDLC encapsulation". Here "idleness octets" are employed; the link is transmitting bits constantly, so receiver and transmitter always remain synchronized. Thus an Ethernet preamble-type encapsulation is not needed or desired. McCoy Expires August 2001 5 draft-mccoy-pppext-pppoephy-00.txt February 2002 Note "octet stuffing" is needed so the PPP frame may consist of an arbitrary bit string, just as in the case of Ethernet`s WIS protocol. In order to retain the defined Ethernet layer 1 encoding, the "PPP over Ethernet Layer 1" protocol MUST necessarily adopt Ethernet`s layer 1 method of encapsulation. Thus this document defines how PPP must be encapsulated within Layer 1 Ethernet`s preamble scheme, and for 10GbE, PPP must be encapsulated as Ethernet`s WIS scheme. 6. Ethernet Media Independence While the original Ethernet did not specify "media independence" for its own sake, it did separate the controller and the transceiver, having the same effect. The result was the 10Mbps Ethernet Attachment Unit Interface (AUI). Subsequently 100Mbps Ethernet explicitly defined media independence via its Medium-Independent Interface (MII). This successful exercise continued with the logically equivalent 1GbE Gigabit MII (GMII), and the 10GbE Extended GMII (XGMII). In Ethernet, the AUI is optional for all 10Mbps Ethernet interfaces, MII is optional for 10Mbps DTE interfaces and for 100Mbps DCE interfaces, GMII is optional for 1Gbps DTE interfaces, and XGMII is required for 10GbE DCE. However, this document considers these entities as MUSTs, as the emphasis is upon DCE operation. In all cases the MAC controller (or Ethernet controller) provided a sequence of bit strings as input to the Ethernet physical layer, which by definition generates the physical layer encapsulation. The PPP over Layer 1 Ethernet protocol proposed here MUST retain physical media independence. This is done by specifying all Medium- Independent Interface clauses requiring modification for the encapsulation of PPP frames. 6.1 Ethernet Full Duplex Layer 1 Alternatives The following is a brief review of the various Ethernet physical layer encoding and decoding protocol in the full duplex, point-to- point context. The IEEE defines 16 physical layer interfaces capable of full duplex point-to-point operation, namely: 10BASE-T 2-pair Category 3/4/5 UTP 10BASE-FL 2 optical fibers (62.5 um; 850 nm) 100BASE-TX 2-pair Category 5 UTP, 2-pair STP McCoy Expires August 2001 6 draft-mccoy-pppext-pppoephy-00.txt February 2002 100BASE-FX 2 optical fibers (62.5 um; 850 nm) 100BASE-T2 2-pair Category 3/4/5 UTP 1000BASE-SX 2 optical fibers (62.5/50 um; 850 nm) 1000BASE-LX 2 optical fibers (62.5/50/10 um; 1300 nm) 1000BASE-CX 2-pair STP 1000BASE-T 4-pair Category 5 UTP 10GBASE-SR 2 optical fibers (850 nm) 10GBASE-LR 2 optical fibers (1310 nm) 10GBASE-ER 2 optical fibers (1550 nm) 10GBASE-LX4 2 optical fibers (1310 nm WWDM) 10GBASE-SW 2 optical fibers (850 nm WIS) 10GBASE-LW 2 optical fibers (1310 nm WIS) 10GBASE-EW 2 optical fibers (1550 nm WIS) Note 10Mbps, 100Mbps, 1Gbps, and 10Gbps rates are defined, and there is also consideration of a further 40Gbps definition. Note also, that in the "telco" sense, these do not constitute a digital hierarchy. That is, 100Mbps Ethernet does not consist of ten 10Mbps Ethernet sub-channels, etc. Note that most of these definitions are for LAN use, but increasingly link lengths of up to 40km (even 70km) over single mode fibers (SMF) are now possible. Also,the 10 um fiber is SMF by definition; others are multi-mode. As stated below, the WIS interface is explicitly defined for compatibility with common carrier "telco" SONET and SDH protocols. Note also that none of these full duplex serial line implementations make use of the Media Access Control protocol, even though they retain the MAC frame. That is, in full duplex serial line mode, Ethernet no longer uses the Carrier Sense Multiple Access/Collision Detect algorithm, which is sometimes thought of as the "heart and soul" of Ethernet. 6.2 Ethernet Layer 1 Encapsulation For completeness a review of how the Ethernet frame is encapsulated on a layer 1 signal, as this implies how PPP will necessarily be encapsulated follows. Historically, the Ethernet Layer 1 signal power is literally "off" between adjacent MAC frames hence its "idleness code" is indicated by lack of any signal. A consequence of this is that a receiver must necessarily resynchronize with the transmitter every time an Ethernet frame is sent over a physical link. Resynchronization is accomplished by pre-pending a "preamble/start- of-frame" field to each Ethernet frame, consisting of 64 bits 101010...1011. This allows the receiver to synchronize to the bit stream and then with the actual beginning of an Ethernet frame. McCoy Expires August 2001 7 draft-mccoy-pppext-pppoephy-00.txt February 2002 If link utilization is low and packets relatively large (as is typical in statistical multiplexing) this is a perfectly acceptable overhead, and works very well. Recently a new Ethernet encapsulation has been defined for 10GbE, termed the WAN Interface Sublayer officially, and sometimes SONET- Lite informally [16]. Here the usual Ethernet preamble technique is not employed, as SONET layer 1 framing is used, which is a byte synchronous constant bit rate technology. That is, the OC-192c rate is essentially 10Gbps, and so a single concatenated Synchronous Payload Envelope is sufficient. This allows WIS encapsulation to be backward compatible with the huge installed base of SONET ADM and DCS, constituting the worldwide WAN. An important point of WIS is that idleness octets are transmitted along with the particular flow of Ethernet frames. Thus idleness is a particular encoding, that might also occur in an Ethernet frame. Consequently some sort of stuffing is needed within an Ethernet frame to permit it to be an arbitrary bit string. 6.3 Ethernet Physical Encodings Many physical layer encodings have been defined for the various Ethernet incarnations. PPP over Ethernet Layer 1 will necessarily employ these, so they are enumerated here. 10BASE-T and 10BASE-FL employed Manchester encoding, with 2 baud/bit. Optical fiber interfaces use a EIA/TIA 568 connector. 100BASE-xX employed 4B/5B encoding, meaning 1.25 baud/bit. 100BASE- T2 employed PAM 5x5 at 0.5 baud/bit. This also uses the EIA/TIA 568 optical fiber connector. Current Gigabit Ethernet employs 8B/10B encoding, also meaning 1.25 baud/bit, designed originally for Fibre Channel. The SC connector is used for the fiber optic interfaces. The proposed 10GBASE-x will use 64B/66B encoding, with the exception of 10GBASE-LX4, which will use 8B/10B encoding. 7.0 Defining a PPP over Layer 1 Ethernet Encapsulation This document now defines the logical implementation of PPP over Ethernet Layer 1. Precisely this means submitting PPP frames to Ethernet`s Medium Independent Interface, in place of Ethernet MAC frames, thereby allowing PPP over all and each of the full duplex point-to-point Ethernet Layer 1 encapsulations. Of course this requires some changes "beneath" the MII interface, such as finite state machines, etc. The actual physical implementation of the logical interface is beyond the scope of this document. McCoy Expires August 2001 8 draft-mccoy-pppext-pppoephy-00.txt February 2002 All of the Ethernet "clauses" requiring change for the PPP over Ethernet Layer 1 encapsulation are enumerated below. All clauses not enumerated above do not require modification for the proper encapsulation of PPP. Clauses 6 and 7, Physical Layer Signaling (PLS) This sublayer is a MUST, as it provides the 10Mpbs Manchester encoding/decoding to the AUI cable. However, the Carrier Sense and Collision Detection capability MUST NOT be implemented. Clause 7 Attachment Unit Interface The cable capability MUST be implemented. Clause 35: Reconciliation Sublayer and MII/GMII/XGMII The state machine necessary for PPP MUST replace the MAC state machine. Clause 36, Physical Coding sublayer and Physical Media Attachment This sublayer (1000BASE-X) MUST be accomplished. Clause 37: Auto-Negotiation Auto-Negotiation, Clause 37, MUST NOT be accomplished. Thus there are no Ethernet parameters to set, such as "duplicity" and "flow control". PPP has its own negotiation capability, which MUST be retained. Clause 38, Physical Medium-Dependent These baseband medium types 1000BASE-LX and 1000BASE-SX (fiber) MUST be accomplished. Clause 39, Physical Medium-Dependent These medium sublayer and baseband medium type 1000BASE-CX (STP copper) MUST be accomplished. Clause 40, Physical Medium-Dependent This sublayer and baseband medium type 1000BASE-T (UTP copper) MUST be accomplished. Clause 41, Repeater for 1000Mbps Baseband Networks This capability MAY be accomplished. McCoy Expires August 2001 9 draft-mccoy-pppext-pppoephy-00.txt February 2002 Clause 42, System considerations for multisegment 1000 Mbps Baseband Networks This capability MAY be accomplished. Clause 46, Reconciliation Sublayer (RS) and 10 Gigabit Media Independent Interface (XGMII). This provides interconnection between the MAC layer and the Physical Layer; a MUST except the serial input is from PPP. Clause 47, XGMII Extender Sublayer (XGXS) and 10 Gigabit Attachment Unit Interface (XAUI) This capability is optional in Ethernet and is a MAY for this protocol. Clause 48, Physical Coding Sublayer (PCS) and Physical Medium Attachment (PMA) This sublayer, for Ethernet type 10GBASE-X, is a MUST. 7. Security Considerations This document does not discuss the security implications of PPP over Layer 1 Ethernet. It is assumed that PPP authentication and encryption/decryption schemes are adequate and applicable. IPsec also applies as needed. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 Carpenter, B, Editor, "Architectural Principles of the Internet", RFC 1958, June 1996 4 Deering, Steve, "51st IETF Plenary Presentation," August 2001. 5 ANSI T1X1.5/2001-024R4, "Synchronous Optical Network (SONET)Generic Framing Procedure (GFP)", June 2001 6 Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994 7 Malis, A., et. al., "PPP over SONET/SDH", RFC 2615, June 1999 McCoy Expires August 2001 10 draft-mccoy-pppext-pppoephy-00.txt February 2002 8 Mamakos, L., et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 9 Herrera, A, et. al., "A Framework for IP over RPR",draft-ietf- ipor-pr-framework, February 2001 10 Simpson, W., "PPP in Frame Relay," RFC 1973, June 1996. 11 Gross, G., et. al., "PPP over AAL5," RFC 2364, July 1998 12 IEEE 802.17 Resilent Packet Ring Working Group(not yet released) 13 Kastenholz, F., "The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol," RFC 1474, June 1993 14 Sklower K., et. al., "The PPP Multilink Protocol (MP)," RFC 1717 August 1996 15 Pazhyannur R., et.al, "PPP Multiplexing," RFC 3153 August, 2001. 16 IEEE Draft Standard 802.3z, Media Acess Control (MAC) Parameters,Physical, Repeater and Management Parameters for 1000 Mb/s Operation(not approved at time of writing) 9. Acknowledgments The authors extend our appreciation to our Tellabs management for encouraging its employees to participate in standards body forms. 10. Author`s Addresses Earl McCoy Tellabs Operations, Inc. One Tellabs Center 1415 Diehl Road Naperville, IL 60563 Phone: +1 630-798-3673 Email: Earl.McCoy@tellabs.com John Sauer Tellabs Operations, Inc. One Tellabs Center 1415 Diehl Road Naperville, IL 60563 Phone: +1 630-798-5581 Email: John.Sauer@tellabs.com Full Copyright Statement This document and translations of it may be copied and furnished to McCoy Expires August 2001 11 draft-mccoy-pppext-pppoephy-00.txt February 2002 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 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. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK ORCE 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 ITNESS FOR A PARTICULAR PURPOSE." McCoy Expires August 2002 12