Network Working Group James Carlson
INTERNET-DRAFT WorkingCode
Intended status: Proposed Standard May 27, 2010
Expires: November 27, 2010
PPP TRILL Protocol Control Protocol
<draft-ietf-pppext-trill-protocol-01.txt>
Copyright Notice
Copyright (c) 2010 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 November 27, 2010.
Carlson expires November 2010 [Page 1]
INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2010
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.
1. 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.
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].
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
Carlson expires November 2010 [Page 2]
INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2010
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.
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.
Carlson expires November 2010 [Page 3]
INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2010
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 Ethernet format except that the Outer MAC
header and Ethertype are replaced by the PPP headers and Protocol
Field. Both user data and ESADI packets are encoded in this format.
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.
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.
2. RBridges are never appointed forwarders on PPP links. If an
implementation includes Bridging Control Protocol (BCP) [4], then
it must ensure that only 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 nor to any 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.
Carlson expires November 2010 [Page 4]
INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2010
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
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.
5. IANA Considerations
IANA has assigned three similarly-numbered PPP Protocol field values,
TBD-00XX, TBD-40XX, and TBD-80XX, as described in Section 1 of this
document.
6. References
6.1. Normative
[1] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)," RFC
1661, July 1994
[2] R. Perlman, et al., "RBridges: Base Protocol Specification,"
draft-ietf-trill-rbridge-protocol-16.txt, in RFC Editor queue
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14 and RFC 2119, March 1997
6.2. Informative
[4] M. Higashiyama, et al., "PPP Bridging Control Protocol (BCP),"
RFC 2878, July 2000
Carlson expires November 2010 [Page 5]
INTERNET-DRAFT The PPP TRILL Protocol Control Protocol May 2010
7. Acknowledgments
The author thanks Radia Perlman and Donald Eastlake 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 2010 [Page 6]