Network Working Group James Carlson INTERNET-DRAFT WorkingCode Intended status: Proposed Standard May 23, 2011 Expires: November 23, 2011 PPP TRILL Protocol Control Protocol Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Comments are solicited and should be sent to the PPP Extensions or TRILL working group mailing list and/or the author. This Internet-Draft will expire on November 23, 2011. Carlson expires November 2011 [Page 1] INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2011 Abstract The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. 1. Introduction The TRILL Protocol [1] defines a set of mechanisms used to communicate between RBridges. These devices can bridge together large 802 networks using link-state protocols in place of the traditional spanning tree mechanisms. Over Ethernet, TRILL uses two separate Ethertypes to distinguish between encapsulation headers, which carry user data, and link-state messages, which compute network topology using a protocol based on ISO IS-IS. These two protocols must be distinguished from one another, and segregated from all other traffic. In a network where PPP [2] is used to interconnect routers (often over telecommunications links), it may be advantageous to be able to bridge between Ethernet segments over those PPP links, and thus integrate remote networks with an existing TRILL cloud. The existing Bridging Control Protocol (BCP) [5] allows direct bridging of Ethernet frames over PPP. However, this mechanism is inefficient and inadequate for TRILL, which can be optimized for use over PPP links. To interconnect these devices over PPP links, three protocol numbers are needed, and are reserved as follows: Value (in hex) Protocol Name TBD-00XX TRILL Network Protocol (TNP) TBD-40XX TRILL Link State Protocol (TLSP) TBD-80XX TRILL Network Control Protocol (TNCP) The usage of these three protocols is described in detail in the following section. 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 [3]. Carlson expires November 2011 [Page 2] INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2011 2. PPP TRILL Negotiation The TRILL Network Control Protocol (TNCP) is responsible for negotiating the use of the TRILL Network Protocol (TNP) and TRILL Link State Protocol (TLSP) on a PPP link. TNCP uses the same option negotiation mechanism as LCP. TNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. Any TNCP packets received when not in that phase MUST be silently ignored. The encapsulated network layer data, carried in TNP packets, and topology information, carried in TLSP packets, MUST NOT be sent unless TNCP is in Opened state. If a TNP or TLSP packet is received when TNCP is not in Opened state and LCP is Opened, an implementation SHOULD respond using LCP Protocol-Reject. 2.1. TNCP Packet Format Exactly one TNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex TBD-80XX (TNCP). A summary of the TNCP packet format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code Only LCP Code values 1 through 7 (Configure-Request, Configure- Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. All other codes SHOULD result in a TNCP Code-Reject reply. Identifier and Length These are as documented for LCP. Data This field contains data in the same format as for the corresponding LCP Code numbers. Carlson expires November 2011 [Page 3] INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2011 Because no Configuration Options have been defined for TNCP, negotiating the use of TRILL Protocol with IS-IS for the link state protocol is the default when no options are specified. A future document may specify the use of Configuration Options to enable different TRILL operating modes, such as the use of a different link state protocol. 2.2. TNP Packet Format When TNCP is in Opened state, TNP packets MAY be sent by setting the PPP Protocol field to hex TBD-00XX (TNP) and placing the TRILL- encapsulated data in the PPP Information field. A summary of this format is provided below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress (RB1) Nickname | Inner Destination MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This is identical to the TRILL Ethernet format except that the Outer MAC header and Ethertype are replaced by the PPP headers and Protocol Field, and the Ethernet FCS is not present. Both user data and ESADI packets are encoded in this format. The PPP FCS follows the encapsulated data on links where the PPP FCS is in use. Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC addresses, so no outer MAC is present. (HDLC addresses MAY be present in some situations; such usage is outside the scope of this document.) 2.3. TLSP Packet Format When TNCP is in Opened state, TLSP packets MAY be sent by setting the PPP Protocol field to hex TBD-40XX (TLSP) and placing the IS-IS Payload in the PPP Information field. Note that point-to-point IS-IS links have only an arbitrary Circuit ID, and do not use MAC addresses for identification. Carlson expires November 2011 [Page 4] INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2011 3. TRILL PPP Behavior 1. On a PPP link, TRILL always uses P2P Hellos. There is no need for TRILL-Hello frames, nor is per-port configuration necessary. P2P Hello messages, per section 9.3 of [6], do not use Neighbor IDs. 2. RBridges are never appointed forwarders on PPP links. If an implementation includes BCP [5], then it MUST ensure that only one of BCP or TNCP is negotiated on a link, and not both. If the peer is an RBridge, then there is no need to pass unencapsulated frames, as the link can have no TRILL-ignorant peer to be concerned about. If the peer is not an RBridge, then TRILL is not possible. 3. An implementation that has only PPP links might have no OUI that can form an IS-IS System ID. Resolving that issue is outside the scope of this document, but see [8] for one mechanism that should be considered in this situation. 4. MTU-probe and MTU-ack messages are not needed on a PPP link. Implementations MUST NOT send MTU-probe and SHOULD NOT reply to these messages. The MTU computed by LCP SHOULD be used instead. Negotiating an LCP MTU of at least 1524, to allow for an inner Ethernet payload of 1500 octets, is RECOMMENDED. 4. Security Considerations Existing PPP and IS-IS security mechanisms may play important roles in a network of RBridges interconnected by PPP links. A PPP authentication mechanism (such as CHAP [9] or EAP [10]) protects the establishment of a link, and identifies a link with a known peer. The IS-IS authentication mechanisms [11] prevent fabrication of link-state control messages. PPP link encryption mechanisms can protect the confidentiality and integrity of all packets on the link. And when PPP is run over tunneling mechanisms, such as L2TP, other security protocols are available. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document. Implementors are encouraged to evaluate their own overall network and system security issues, and to use the existing security mechanisms where appropriate. Carlson expires November 2011 [Page 5] INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2011 5. IANA Considerations IANA has assigned three PPP Protocol field values, TBD-00XX, TBD- 40XX, and TBD-80XX, as described in Section 1 of this document. All TNCP Configuration Options except 00 are "Unassigned" and available for future use, based on "IETF Review," as described in BCP 26 [4]. Option 00 is allocated for use with Vendor Specific Options, as described in [7]. [IANA Note: new registry "TNCP Configuration Options" needed under ppp-numbers; details in paragraph above.] 6. References 6.1. Normative [1] R. Perlman, et al., "RBridges: Base Protocol Specification," draft-ietf-trill-rbridge-protocol-16.txt, in RFC Editor queue [2] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)," RFC 1661, July 1994 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14 and RFC 2119, March 1997 [4] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," BCP 26 and RFC 5226, May 2008 6.2. Informative [5] M. Higashiyama, et al., "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)," RFC 3518, April 2003 [6] D. Oran, Editor, "OSI IS-IS Intra-domain Routing Protocol," RFC 1142, February 1990 [7] W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997 [8] W. Simpson, "Generation of Unique IS-IS System Identifiers," (draft-simpson-isis-ppp-unique), work in progress, March 2011 [9] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996 Carlson expires November 2011 [Page 6] INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2011 [10] B. Aboba, et al., "Extensible Authentication Protocol (EAP)," RFC 3748, June 2004 [11] T. Li and R. Atkinson, "IS-IS Cryptographic Authentication," RFC 5304, October 2008 7. Acknowledgments The author thanks Linda Dunbar, Donald Eastlake, Radia Perlman and William A. Simpson for their comments and help. 8. Authors' Addresses James Carlson WorkingCode 25 Essex Street North Andover, MA 01845 USA Phone: +1-781-301-2471 Email: carlsonj@workingcode.com Carlson expires November 2011 [Page 7]