Point-to-Point Protocol Extensions Working Group J. Sadler Internet Draft B. Mack-Crane Document: draft-sadler-pppext-disc-00.txt Tellabs Category: Standards Track Expiration Date: May 2001 November 2001 Neighbor Discovery via PPP draft-sadler-pppext-disc-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. 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 Work has been progressing in the Common Control and Measurement Protocol (CCAMP) working group on the application of MPLS technology to non-packet switching networks. Development of the Generalized MPLS (GMPLS) signaling draft [1] has allowed for Optical, SONET/SDH, and spatial switching systems to be controlled using IP protocols. In a GMPLS network, the path that a TDM connection will use is developed using constraint based routing. The developed route utilizes TDM link state information announced via OSPF or IS-IS by other nodes in the network. However, a node cannot advertise the existence of a link without first identifying the remote node connected to the link and the capabilities of the neighboring node. In a packet network, this function would typically be accomplished using OSPF or IS-IS Hello messages repeated every 10 or so seconds. However, the TDM link cannot transmit similar messages because the port terminating the link cannot be shared between a TDM service user and the OSPF/IS-IS termination function. Sadler PPPEXT WG - August 2001 1 draft-sadler-pppext-lapd-00.txt August 2001 As a result, a different mechanism is needed to identify the remote node connected to the link. This draft discusses an extension to PPP that would allow a node to identify the neighboring node at link commissioning time. 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. 3. Motivation Work has been progressing in the Common Control and Measurement Protocol (CCAMP) working group on the application of MPLS technology to non-packet switching networks. Development of the Generalized MPLS (GMPLS) signaling draft [1] has allowed for Optical, SONET/SDH, and spatial switching systems to be controlled using IP protocols. In a GMPLS network, the path that a TDM connection will use is developed using constraint based routing. The developed route utilizes TDM link state information announced via OSPF or IS-IS by other nodes in the network. However, a node cannot advertise the existence of a link without first identifying the remote node connected to the link and the capabilities of the neighboring node. In a packet network, this function would typically be accomplished using OSPF or IS-IS Hello messages repeated every 10 or so seconds. However, the TDM link cannot transmit similar messages because the port terminating the link cannot be shared between a TDM service user and the service provider's OSPF/IS-IS termination function. As a result, a different mechanism is needed to identify the remote node connected to the link, and discover its service capabilities. Determining the identity of a neighbor and determining its capabilities can be treated as two separate functions. This is partly justified since neighbor discovery requires use of the in- band link to learn the neighbor's identity and the name that the neighbor has associated with the port it is transmitting on. The remainder of the capability information could be carried out of band using a service capability exchange protocol such as LMP [2]. Separation of neighbor discovery from service capability exchange is further justified since associating a link with a neighbor only needs to be done when it is first commissioned or when a link is reconnected. The former event is initiated by management, and the latter can be initiated automatically when link's state transitions from down to up. As a result neighbor discovery does not need to be a continuous process. Sadler PPPEXT WG - August 2001 2 draft-sadler-pppext-lapd-00.txt August 2001 However, capability of a neighboring node may change when software containing new feature packages is loaded. Consequently, service capability exchange, which is outside the scope of this document, needs to be a continuous process. This draft discusses an extension to PPP that provides for neighbor discovery. 4. Requirements for Neighbor Discovery 4.1 Independence from Network Layer negotiation While a remote interface may support Neighbor Discovery, the remote system may not be packet switching capable. Therefore, Neighbor Discovery MUST be independent of network layer negotiation. This will prevent a link from being mistakenly placed into service as a packet switching link. 4.2 Naming Neighbor Discovery is an automatic process that allows two neighbors to identify the remote name of interfaces associated with a link. These names will then be used by a management or control plane entity to contact the remote system over the control network to exchange interface capability information. 4.4 Misconnection failure modes It is possible that in deploying a link between two neighbors that the cabling was not properly installed. As a result, Neighbor Discovery may not be able to complete successfully. Instead of failing with no information, neighbor discovery MUST be able to assist in debugging the misconnection. Five different misconnection scenarios exist: o Transmit/Receive reversal o Transmit/Receive half-connection o Transmit/Receive split 1 port -> 2 ports (1 NE -> 1 NE) o Transmit/Receive split 2 ports -> 2 ports (1 NE -> 1 NE) o Transmit/Receive split 1 NE -> 2 NEs 4.5 When neighbor discovery occurs As stated previously, neighbor discovery MUST ONLY be done when a link becomes available. This will occur at initial link turn-up as well as whenever the link is returned to service. Neighbor discovery MUST NOT occur continuously, as the bearer may not be able to simultaneously support discovery and user traffic. 5. PPP Operating environment PPP is a data link protocol that provides for negotiation of configuration information prior to establishing network connectivity Sadler PPPEXT WG - August 2001 3 draft-sadler-pppext-lapd-00.txt August 2001 over a link. This configuration negotiation takes place in a number of phases. These phases, as captured in RFC 1661 [3] are as follows: o Link establishment o Authentication o Network layer negotiation RFC 1661 [3] further specifies a common negotiation protocol and FSM to be used by all of these phases. A full-duplex connection must exist between neighbors for the protocol to successfully complete. 6. Neighbor Discovery Mechanism 6.1 Overview 6.1.1 Independence from Network Layer negotiation The Neighbor Discovery function will be handled as a new LCP option. Use of an LCP option is further justified in section 6.1.3 6.1.2 Interface Name Since interfaces do not exist independent of systems, the interface name can be described by the systemĘs control address and a system- unique interface id. However, since more than one network protocol may be in use in the control network, the neighbor discovery protocol MUST also specify the protocol context being used for the control address. The interface name format will therefore be: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol | Address Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Control Plane Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are defined as follows: Interface ID Unique Port ID for this port (persistent) Protocol IANA EtherType Identifier Address Len Control Plane Addr Length (in half-octets) Control Plane Addr Control Plane Address to be contacted As a part of the address exchange, the two neighboring nodes MUST negotiate a common protocol. Sadler PPPEXT WG - August 2001 4 draft-sadler-pppext-lapd-00.txt August 2001 6.1.3 Distinguishing Multiple Concurrent Neighbor Discovery processes Since there may be more than one neighbor discovery process in progress at the same time, the sender MUST include a locally unique discovery session ID in the CONF-REQ message. This ID may be a monotonically increasing 32-bit value, which automatically recycles to 0. Since the number of discovery sessions that occurs in a short period of time (i.e. less than 5 minutes) is expected to be significantly less than 2^32, no process is necessary to handle recycling of the session ID. 6.1.4 Misconnection failure modes Because successful LCP negotiation is dependent on a full-duplex link existing between two neighboring nodes, a misconnection will not allow LCP to complete successfully. As a result, any support for identifying a misconnection must be done via an LCP option. Given that a misconnection may occur for any supported Interface, the exchange of Interface Names provides the best information for debugging a misconnection. 6.2 Protocol realization 6.2.1 LCP option format The resulting LCP option looks like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCPOpt (0xXX) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Term Point ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol | Address Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Control Plane Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are defined as follows: LCPOpt LCP Option Id Length LCP Option Length Disc Session ID Locally Unique Discovery Session ID Interface ID Unique ID for this port (persistent) Protocol IANA EtherType Identifier Address Len Control Plane Addr Length (in half-octets) Control Plane Addr Control Plane Address to be contacted Sadler PPPEXT WG - August 2001 5 draft-sadler-pppext-lapd-00.txt August 2001 6.2.2 Behavior The Neighbor Discovery option functions similarly to the IPCP 4 IP Address Configuration option. Specifically: When generating a CONF-REQ, the system MUST indicate the Protocol and Control Plane Address of the Control Plane entity that should be contacted by the receiver of Neighbor Discovery option. In cases where the originating system should be configured by the remote system, the originating system MUST indicate the Protocol it would like to be configured for, but the Address Length field should be set to 0x00, and the variable length Control Plane Address field should be empty. When receiving a CONF-REQ, the system MUST validate the Protocol sent is supported. If not, then a CONF-NAK MUST be sent with the Protocol field set to the ID of a supported Protocol. If the received CONF-REQ has an Address Length of 0x00, then a CONF- NAK SHOULD be returned with the Control Plane Address that should be used by the remote system. If no Control Plane Address has been configured, then a CONF-NAK MUST be returned with Address Length set to 0x00. If the CONF-REQ received is valid (i.e. matches any pre-configured parameters), then a CONF-ACK MAY be sent. When receiving a CONF-NAK, the system should create a new CONF-REQ based on the information provided by the CONF-NAK. If the Protocol returned is supported, then the new CONF-NAK SHOULD use a configured address within that Protocol. If no configured address exists and one is supplied in the CONF-NAK, then the supplied address should be used. 7. Security Considerations This draft introduces no new security considerations. 8. References 1 P. Ashwood-Smith, et al., "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized- signaling-06.txt, Work in progress. October 2001. 2 J. Lang, et al., "Link Management Protocol (LMP)", Internet Draft, draft-ietf-ccamp-lmp-02.txt, Work in progress. November 2001. 3 W. Simpson, et al., "Point to Point Protocol (PPP)", RFC 1661, July 1995. Sadler PPPEXT WG - August 2001 6 draft-sadler-pppext-lapd-00.txt August 2001 4 G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. 9. Acknowledgments The Authors would like to acknowledge Dmitry Levandowski for his assistance in developing this document. 10. Author's Addresses Jonathan Sadler Tellabs Operations, Inc. 27555 Diehl Rd Warrenville, IL 60555 Phone: +1 630-848-7741 Email: Jonathan.Sadler@tellabs.com Ben Mack-Crane Tellabs Operations, Inc. 27555 Diehl Rd Warrenville, IL 60555 Phone: +1 630-848-7875 Email: Ben.Mack-Crane@tellabs.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to 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 Standards process must be followed, or as required to translate it into Sadler PPPEXT WG - August 2001 7