PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
Extracted elements (23)
No Configuration Options have been defined for TNCP; therefore, negotiating TRILL with IS-IS as the link-state protocol is the default when no options are specified. A future document may define Configuration Options to enable different TRILL operating modes.
PPP nodes do not have MAC addresses, so no outer MAC is present in the TNP format. HDLC addresses MAY be present in some situations, but such usage is outside the scope of this document. This differs from the TRILL Ethernet encapsulation which includes an Outer MAC header.
The existing Bridging Control Protocol (BCP, RFC 3518) allows direct bridging of Ethernet frames over PPP but is inefficient and inadequate for TRILL. A dedicated set of protocol numbers enables TRILL to be optimized for use over PPP links.
RBridges are never appointed forwarders on PPP links. If the peer is not an RBridge, TNCP negotiation fails and TRILL is not used on the link, ensuring TRILL does not activate on links without a compatible peer.
All TNCP Code values other than LCP codes 1 through 7 SHOULD result in a TNCP Code-Reject reply.
If an implementation includes BCP (RFC 3518), it MUST ensure that only one of BCP or TNCP is negotiated on a link, and not both. If the peer is an RBridge, there is no need to pass unencapsulated frames.
It is strongly RECOMMENDED that all TRILL implementations have at least one zero-configuration mechanism to obtain a valid IS-IS System ID, since a PPP-only implementation may have no OUI to form a System ID.
Negotiating an LCP MTU of at least 1524 octets, to allow for an inner Ethernet payload of 1500 octets, is RECOMMENDED on TRILL PPP links.
On a PPP link, TRILL always uses point-to-point (P2P) Hellos; there is no need for TRILL-Hello frames or per-port configuration. The three-way IS-IS handshake using extended circuit IDs is required on point-to-point links such as PPP.
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.
TNP and TLSP packets MUST NOT be sent unless TNCP is in the Opened state. If a TNP or TLSP packet is received when TNCP is not in the Opened state and LCP is in the Opened state, an implementation MUST silently discard the unexpected packet.
TRILL MTU-probe and MTU-ack messages are not needed on PPP links. Implementations MUST NOT send MTU-probe messages and SHOULD NOT reply to them. The MTU computed by LCP SHOULD be used instead.
The TNP packet header includes V (2 bits), R (2 bits), M (1 bit), Op-Length (5 bits), Hop Count (8 bits), Egress (RB2) Nickname (16 bits), and Ingress (RB1) Nickname (16 bits), followed by the Inner Destination MAC. Both user data and ESADI packets use this format.
The TRILL Network Control Protocol (TNCP) is responsible for negotiating the use of TNP and TLSP on a PPP link. It uses the same option negotiation mechanism and state machine as LCP (Section 4 of RFC 1661).
Three PPP protocol numbers are reserved for TRILL over PPP: 005d (TRILL Network Protocol, TNP), 405d (TRILL Link State Protocol, TLSP), and 805d (TRILL Network Control Protocol, TNCP). These allow TRILL encapsulation headers and link-state messages to be distinguished from each other and from other PPP traffic.
IANA assigned three PPP Protocol field values: 005d (TRILL Network Protocol, TNP), 405d (TRILL Link State Protocol, TLSP), and 805d (TRILL Network Control Protocol, TNCP), as described in Section 1.
IANA created a new 'PPP TNCP Configuration Option Types' registry in the PPP-Numbers registry, using the same format as the existing 'PPP LCP Configuration Option Types' registry. All option types except 0 are Unassigned and available for future use via IETF Review. Option 0 is allocated for Vendor-Specific Options per RFC 2153.
For greater authentication flexibility than CHAP, EAP (RFC 3748) is a good alternative. For confidentiality and integrity of all PPP link packets, the PPP Encryption Control Protocol (ECP, RFC 1968) can be used. When PPP runs over tunneling protocols such as L2TP, tunnel security protocols may also be available.
IS-IS authentication mechanisms (RFC 5304, RFC 5310) prevent fabrication of link-state control messages at the TRILL IS-IS layer. PPP CHAP (RFC 1994) is RECOMMENDED when a PPP layer authentication mechanism is needed to protect link establishment and identify a known peer.
Not all implementations need PPP-layer security mechanisms; some deployments operate in trusted environments or rely on other security layers. For applications involving sensitive data, end-to-end security should always be considered in addition to link security to provide security in depth.
The TNCP packet format consists of a 1-octet Code field (LCP codes 1-7 only), a 1-octet Identifier field, a 2-octet Length field, and a variable-length Data field formatted as described in RFC 1661 Section 5. The PPP Protocol field is set to hex 805d.
TLSP packets (PPP Protocol field 405d) carry exactly one IS-IS Payload (RFC 6325 Section 4.2.3) in the PPP Information field. Point-to-point IS-IS links use only an arbitrary circuit ID and do not use MAC addresses for identification.
TNP packets (PPP Protocol field 005d) carry exactly one TRILL-encapsulated packet in the PPP Information field. The format is identical to the TRILL Ethernet encapsulation (RFC 6325 Section 4.1) except that the Outer MAC header and Ethertype are replaced by PPP headers and Protocol Field, and the Ethernet FCS is absent.