Network Working Group                                      James Carlson
INTERNET-DRAFT                                               WorkingCode
Intended status: Proposed Standard                       January 6, 2011
Expires: July 6, 2011


                  PPP TRILL Protocol Control Protocol
               <draft-ietf-pppext-trill-protocol-02.txt>

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
   <pppext@ietf.org> or TRILL working group <rbridge@postel.org> mailing
   list and/or the author.

   This Internet-Draft will expire on July 6, 2011.





Carlson                    expires July 2011                    [Page 1]

 
INTERNET-DRAFT  The PPP TRILL Protocol Control Protocol     January 2011


Abstract

   The Point-to-Point Protocol (PPP) [1] 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 support for
   Transparent Interconnection of Lots of Links (TRILL) Protocol,
   allowing direct communication between Routing Bridges (RBridges) via
   PPP links.


.  Introduction

   The TRILL Protocol [2] 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 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 BCP 14 [3].






Carlson                    expires July 2011                    [Page 2]

 
INTERNET-DRAFT  The PPP TRILL Protocol Control Protocol     January 2011


.  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 July 2011                    [Page 3]

 
INTERNET-DRAFT  The PPP TRILL Protocol Control Protocol     January 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 July 2011                    [Page 4]

 
INTERNET-DRAFT  The PPP TRILL Protocol Control Protocol     January 2011


.  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 an
      implementation-dependent matter, but it is expected that, if at
      all possible, some means of minimizing the need for
      administrative configuration SHOULD be considered in order to
      accomplish the RBridge goal of zero configuration.

   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.


.  Security Considerations

   Both PPP authentication and IS-IS authentication mechanisms may play
   important roles in a network of RBridges interconnected by PPP links.
   The PPP authentication mechanism protects the establishment of a
   link, and identifies a link with a known peer.  The IS-IS mechanisms
   prevent fabrication of link-state control messages.

   Implementors are encouraged to use these existing security mechanisms
   where appropriate.


.  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].



Carlson                    expires July 2011                    [Page 5]

 
INTERNET-DRAFT  The PPP TRILL Protocol Control Protocol     January 2011


.  References


6.1.  Normative

   [] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)," RFC
       1661, July 1994

   [] R. Perlman, et al., "RBridges: Base Protocol Specification,"
       draft-ietf-trill-rbridge-protocol-16.txt, in RFC Editor queue

   [] S. Bradner, "Key words for use in RFCs to Indicate Requirement
       Levels," BCP 14 and RFC 2119, March 1997

   [] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs," BCP 26 and RFC 5226, May 2008


6.2.  Informative

   [] M. Higashiyama, et al., "PPP Bridging Control Protocol (BCP),"
       RFC 2878, July 2000

   [] D. Oran, Editor, "OSI IS-IS Intra-domain Routing Protocol,"
       RFC 1142, February 1990

   [] W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997


.  Acknowledgments

   The author thanks Donald Eastlake, Linda Dunbar, and Radia Perlman
   and for their comments and help.


.  Authors' Addresses

   James Carlson
   WorkingCode
   25 Essex Street
   North Andover, MA 01845 USA

   Phone: +1-781-301-2471
   Email: carlsonj@workingcode.com







Carlson                    expires July 2011                    [Page 6]