LMP Link Management Protocol

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

2. Introduction to Control Plane Part one

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

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

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

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

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

8. Link Management Protocol Part two

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

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

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

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

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

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

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

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

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

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

19. 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 }

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

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

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

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

24. 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;

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

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

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

28. 2. B and C send a ChannelStatus message to nodes A and B respectively 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. Example of Fault Localization A B C