1 / 28

LMP Link Management Protocol

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. Residential users. ISP. Services. Common

joanne
Download Presentation

LMP Link Management Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related