LMP Link Management Protocol Francesco Diana diana@dti.unimi.it Umberto Raimondi uraimondi@crema.unimi.it Marco Anisetti Marco.anisetti@unimi.it

Introduction to Control Plane Part one

Network example IP/MPLS Backbone DWDM core Common NMS/EMS Residential users ISP Services Common NMS/EMS VOD 10GbE ring(s) GbE FE/GbE DWDM Access Ring Enterprise Data traffic FE/GbE CWDM Access Ring B/E/GPON Access IP DSLAM PDH Mobile Residential users SDH/SONET Legacy

Switching levels  LSPs PSC = Packet Switch Capable Bundle Fiber n Fiber 1 FSC Cloud LSC Cloud TDM PSC Explicit Label LSPs Time-slot LSPs Fiber LSPs  LSPs PSC = Packet Switch Capable TDM = Time Division Multiplexing LSC = Lambda Switch Capable FSC = Fiber Switch Capable

Signaling functionalities To manage such complex networks some signaling functionalities are required, for instance: Routing Resource reservation Fault localization Connectivity verification As these features may require different types of networks to communicate, the related information cannot be sent over the same channel that carries the data.

Control plane: why? For instance, if signaling information is sent over SONET frames and then wavelength-multiplexed into a DWDM network, that information will be unreadable until it exits the DWDM network. Another reason to keep data and signaling information apart is that if a node detects a fault on a data link, it can still alert its neighbors or a network management system over a different communication channel.

Control plane The set of communication channels over which all signaling information is sent is named Control Plane, in opposition to the Data Plane which carries the data. Many protocols have been defined to manage specific control plane functionalities, e.g. RSVP for resource reservation and OSPF or IS-IS for routing. GMPLS suite encompasses all these control plane features, providing an integrated strategy to manage heterogeneous networks with respect to routing, resource reservation, connectivity verification and fault localization. In this seminar we will focus on an important component of the GMPLS suite, namely the Link Management protocol.

Link Management Protocol Part two

LMP Defined in RFC4204 It manages data links, that is the channels on which the data are carried between two adjacent nodes. It can be used for a variety of equipments including optical crossconnects and photonic switches.

LMP Features Maintain control channel connectivity Neighbor discovery Verify data link connectivity Correlate link property information Localize link failures Suppress downstream alarms

LMP procedures LMP currently consists of four main procedures, of which the first two are mandatory and the last two are optional: Control channel management Link property correlation Link verification Fault management

Control Channel Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. To initiate an LMP adjacency between two nodes, one or more bi-directional control channels MUST be activated.

Neighbor discovery Automatic inventory of links between nodes Allows to detect incorrect physical fiber connections Automatic identification between neighbors There is a need to accurately identify the neighbors so that this information can be shared with the routing protocol for dissemination in the network This allows the routing protocol to build an accurate network topology

Control Channel: Config message (1) To establish a control channel, the destination IP address on the far end of the control channel must be known. This knowledge may be manually configured or automatically discovered (multicast 224.0.0.1). control channels are electrically terminated at each node.

Control Channel: Config message (2) Control channel activation begins with a parameter negotiation exchange using Config, ConfigAck, and ConfigNack messages (LMP objects: negotiable or non-negotiable). To activate a control channel, a Config message MUST be transmitted to the remote node, and in response, a ConfigAck message MUST be received at the local node. The Config message contains: Local Control Channel Id (CC_Id) sender's Node_Id Message_Id for reliable messaging. CONFIG object.

Control Channel: Config message (3) It is possible that both the local and remote nodes initiate the configuration procedure at the same time: The node with the higher Node_Id wins the contention. The ConfigAck express agreement on ALL of the configured parameters (both negotiable and non-negotiable). E.g RFC 4209 (LMP for DWDM) a new LMP-WDM CONFIG object is defined.

Control Channel: keep-alive (1) Control channel connectivity is maintained through LMP Hello messages Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed. These parameters are exchanged in the Config message. The HelloInterval indicates how frequently LMP Hello messages will be sent. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead

Control Channel: keep-alive (2) LMP Hello protocol is a light-weight keep-alive mechanism Hello messages are transmitted in the control channel LMP Hello messages can detect control channel failures quickly For each Hello msg transmitted, the source node must receive an Hello msg with the same sequence number Hello messages use Transmit and Receive sequence numbers (TxSeqNum, RcvSeqNum) to identify msgs of the same session

Control Channel: keep-alive (3) There are two special sequence numbers. TxSeqNum MUST NOT ever be 0. TxSeqNum = 1 is used to indicate that the sender has just started/restarted When TxSeqNum reaches (2^32)-1, the next sequence number used is 2, not 0 or 1. {TxSeqNum=1;RcvSeqNum=0} B A {TxSeqNum=1;RcvSeqNum=1} HelloInterval {TxSeqNum=2;RcvSeqNum=1 }

TE & Data Links Recall that data-bearing links and control channels are not necessarily the same Out-of-band control channel connectivity does not indicate that data bearing link is up Multiple parallel resources (links) in the transport layer may be bundled into a traffic engineering (TE) link for efficient summarization of the resource capacity This process is done through link property correlation

Link Property Correlation Every node must notify the characteristics of its links, e.g. channels number, channel ids,etc… This information is stored on both ends of the link, LMP must guarantee properties alignment

Link Discovery: example Control channel 1 3 2 4 1 3 2 4 Data links Each local port is associated with its corresponding remote port.

Link Property Correlation (1) Three LMP messages are used for correlation LinkSummary, LinkSummaryAck and LinkSummaryNack LinkSummary includes the local and remote link id’s, a list of all data links that comprise the TE link, and various link properties LinkSummary is sent by a node to its adjacent node One of LinkSummaryAck and LinkSummaryNack is sent as a response by the adjacent node E.g. LinkSummaryNack is sent if local and remote TE link types are different

Link Property Correlation (2) If the LinkSummary message is received from a remote node, and the Interface_Id mappings match those that are stored locally, then the two nodes have agreement on the Verification procedure. If the verification procedure is not used, the LinkSummary message can be used to verify agreement on manual configuration. The LinkSummaryAck message is used to signal agreement on the Interface_Id mappings and link property definitions. LinkSummaryNack message MUST be transmitted, indicating which Interface mappings are not correct and/or which link properties are not accepted. If a LinkSummaryNack message indicates that the Interface_Id mappings are not correct and the link verification procedure is enabled, the link verification process SHOULD be repeated for all mismatched, free data links;

Connectivity Verification Optional procedure Test Message sent over data plane, verified using control plane messages Same control channel used to check multiple data links on the same node Note that this procedure can be used to "discover" the connectivity of the data ports

Connectivity Verification over transparent networks Transparent networks = All optical networks without OEO conversion capabilities E.g. A network segment composed by a set of OLAs The connectivity verification requires that the involved nodes can perform OEO conversion The TestMessage must be sent/received over the data plane

Fault localization When a node detects an upstream failure (e.g. a loss of power), it sends a ChannelStatus message upstream The upstream node sends ChannelStatusAck back Upstream node correlates that failure with any failure detected locally If, as an effect of the correlation procedure, a node localizes a fault, it sends a ChannelStatus message to the downstream node to indicate if the channel is failed or OK

Example of Fault Localization 2. B and C send a ChannelStatus message to nodes A and B respectively A B C 1. B and C detect a failure on their input links 4. A does not detect any fault on the input port, and sends a ChannelStatus to B to inform it that the link between them has failed. 3. A ChannelStatusAck message confirms that the ChannelStatus has been received.