Transcript Photonic Path Trace

LMP
Link Management Protocol
Francesco Diana
Umberto Raimondi
[email protected]
[email protected]
Marco Anisetti
[email protected]
Part one
Introduction to Control Plane
Network example
IP/MPLS Backbone
DWDM core
Residential
users
Services
ISP
Common
NMS/EMS
VOD
GbE
10GbE
ring(s)
FE/GbE
Enterprise
DWDM Access
Ring
Data traffic
CWDM Access
Ring
FE/GbE
PDH
IP
DSLAM
B/E/GPON
Access
Residential
users
Mobile
SDH/SONET
Legacy
3/20
Switching levels
PSC
Cloud
TDM
Cloud
LSC
Cloud
FSC Cloud
Fiber 1
LSC
Cloud
TDM
Cloud
PSC
Cloud
Bundle
Fiber n
Explicit
Label LSPs




Time-slot
LSPs
 LSPs
Fiber LSPs
 LSPs
Time-slot
LSPs
Explicit
Label LSPs
PSC = Packet Switch Capable
TDM = Time Division Multiplexing
LSC = Lambda Switch Capable
FSC = Fiber Switch Capable
4/20
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.
5/20
Control plane: why?
For instance, if signaling information is sent
over SONET frames and then wavelengthmultiplexed 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.
6/20
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.
7/20
Part two
Link Management Protocol
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.
9/20
LMP Features

Maintain control channel connectivity
Neighbor discovery
Verify data link connectivity
Correlate link property information

Localize link failures



• Suppress downstream alarms
10/20
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
11/20
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.
12/20
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
13/20
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.
14/20
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.
15/20
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.
16/20
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
17/20
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
18/20
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}
{TxSeqNum=1;RcvSeqNum=1}
A
HelloInterval
B
{TxSeqNum=2;RcvSeqNum=1 }
19/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
20/20
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
21/20
Link Discovery: example
Control channel
1
2
3
4
Data links
1
2
3
4
Each local port is associated with its corresponding
remote port.
22/20
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
23/20
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;
24/20
Connectivity Verification
CONTROL PLANE
Begin Verify Message
CONTROL PLANE
Begin Verify ACK Message
TestStatus Success Message (2)
TestStatus ACK Message (3)
End Verify Message
End Verify ACK Message
Test Message (1)
DATA PLANE




DATA PLANE
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
25/20
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
26/20
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
27/20
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
4. A does not detect any fault on
their input links
the input port, and sends a
ChannelStatus to B to inform it
3. A ChannelStatusAck message
that the link between them has
confirms that the ChannelStatus has
failed.
been received.
28/20