1. LMP Link Management Protocol
Francesco Diana
Umberto Raimondi
Marco Anisetti

2. Introduction to Control Plane
Part one

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

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

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

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