GMPLS Discovery

Discovery
Page - 1
Grotto Networking 2004
Neighbor Discovery
Motivations and previous approaches Data Plane Discovery
Functionality OIF UNI Discovery G.7714.1 Discovery
Control Plane Discovery

Functionality GMPLS LMP
Page - 2 Grotto Networking 2004
Discovery Motivation
Who is on the other side of the link? Analogy: The human hello protocol
Let me find out who that is Its Ms. Orange and she got my name right. Let me double check that I got her name right Nice to meet you Ms. Orange. Hello, Im Mr. Blue Its Mr. Blue. Lets tell him who I am and check his name. Hi, Mr. Blue, Im Ms. Orange
Confirmed that Mr. Blue has got my name right.
Page - 3
But is it worth the effort?

Early days of optical networking very few fibers and no standard protocols for this function No. Current technology lots of fibers Yes!
With commercially available modern DWDM systems, one long-haul fiber pair can contain more than 100 channels, which get broken out into individual fiber pairs at end systems and regenerators.
Page - 4
Neighbor Discovery (Why bother?)

A single box can have lots of neighbors!
Modern SONET/SDH and WDM equipment can support many ports!
Edge Equipment #1
OC-48 lines
Edge Equipment #2 Edge Equipment #N Edge Equipment #N Edge Equipment #N
OC-48 lines
256 ports of OC-48

Edge Equipment #N Edge Equipment #N Edge Equipment #N
Inconsistent Wiring Issues

Consider a bidirectional 1+1 fiber pair
Works fine under normal conditions Works fine if we lose a fiber, 1+1 protection. Maintenance operation: Replace bad fiber
Port 1
Port 12
Port 2
Conduit
Port 13
Page - 6
Box A
Box B
Inconsistent Wiring Problems

Undetected miss-wiring
Big problem we just pulled the wrong fiber!!! Now Box A cant hear from Box B.
Port 1
Port 12
Port 13 Port 2
Page - 7
Box A
Box B
Why do Neighbor Discovery?

Allows automatic inventory of physical links between nodes
Can determine inconsistent physical wiring
Allows automatic identification of nodepair neighbors

Supports accurate neighbor link information for use in routing and signaling
Page - 8
Existing Neighbor Discovery Protocols

A subclass of IP routing protocols contain a hello sub-protocol.
These are known as Interior Gateway Protocols (IGPs). The most widely used IGPs are OSPFv2 and IS-IS OSPFv2 is documented in RFC2328 and is available from www.ietf.org
Page - 9
OSPFs Hello Protocol

Neighbor Discovery (bi-directional communications) Designated Router Election for LANs Dead Router Detection
Version # Type = 1 (hello) Router ID Area ID Checksum Authentication Authentication Network Mask HelloInterval (in seconds) Options RouterDeadInterval (in seconds) Designated Router Backup Designated Router Neighbor Router ID Rtr Pri AuType Packet length
OSPF Hello packet is carried in an IP datagram
Page - 10
OSPFs Hello Protocol

Neighbor State Machine
Start Down Attempt Keep saying hello until something happens...
Hello Received Hello Received
Ive received a hello but dont know if they know me.
Init 1-Way Received 2-Way Received
2-Way
I know them and they know me.
Page - 11
A Solution Exists, can we go home?

No, transport networks (optical in particular) have two complicating factors: Layers in transport networks
Both in WDM and TDM systems makes the question a bit more complicated.
Separation of Control and Data Planes

Further complicates things and gives us more to discover
Page - 12
Layers in WDM Networks

Optical Channel Optical Multiplex Section Optical Transport Section OCh OMS OTS Optical Multiplexor Optical Amplifier #1 Optical Amplifier #2 Optical Add/ Drop multiplexor OTS OTS OCh OMS OTS OCh OMS OTS Optical Demultiplexor
= Optical Fiber = Optical Support Channel for Transport layer = Optical Support Channel for multiplex layer
Page - 13
Layers in TDM Networks

TDM Path Multiplex Section Regenerator Section Path MS RS TDM Multiplexor Regenerator (3R) #1 Regenerator (3R) #2 RS RS Path MS RS TDM demultiplexor
= Optical Fiber = Regenerator section overhead = Multiplex section (line) overhead = User traffic (path layer) = Unused time slots
Page - 14
SONET/SDH Layers
1.5Mbps 6Mbps Multiplexing here 50Mbps 40Gbps Multiplexing here
VT Path Lower order Virtual Containers Higher order Virtual Containers Tandem Connection (optional) Multiplex Section
J2 VT trace J1 Path trace
STS Path Tandem Connection (optional) Line
No Line trace J0 section trace
Section
Regenerator Section
Physical
(a) SONET
STS Path Tandem Connection (optional) Line Section Line Section Section Line Section
Physical
(b) SDH
Line Section Section
Line Section
PTE
TCTE
LTE
STE
STE
LTE
TCTE
PTE
Page - 15
Neighbor Discovery at which layer?

PLR-PLR neighbor discovery STE-STE neighbor discovery STE-STE neighbor discovery
PTE
LTE
STE
PLR
PLR
STE
LTE
PTE
LTE-LTE neighbor discovery
Definitions PLR - Physical Layer Regenerator STE - Section Terminating Equipment LTE - Line Terminating Equipment PTE - Path Terminating Equipment
PLR-PLR neighbor discovery
Generalized Automatic Discovery

ITU G.7714 Concepts Layer Adjacency Discovery
Who are my neighbor peers? Data Plane
Physical Media Adjacency Discovery Data Plane

What is the next box Im physically connected to?
Control Entity Logical Adjacency Establishment Service Capability Exchange

What kinds of things can your peer box or subnetwork do? How are you configured?
Control Plane
If we are going to participate in a control protocol who should I talk to? Control Plane
Layer Adjacency Discovery

Who is my peer at a particular layer in the transport system. Similar to the connectivity supervision management task
Answers the question: Am I connected to the right end point? Usually continuously monitored General mechanism for this is a trail trace
Page - 18
Trail Trace in SONET/SDH

90 By tes
Framing A1 Framing A2 T race J0
Sec ti on Overhead
BIP-8 B1
Orderwi re E1
Us er F1
Section (regenerator section) trace J0
Data Com D1
Data Com D2
Data Com D3
Poi nter H1
Poi nter H2
Poi nter Ac tion H3
Section DCC
Sy nchronous Pay load Env elop 9 rows
BIP-8 B2
APS K1
APS K2
Line Overhead
Data Com D4
Data Com D5
Data Com D6
Data Com D7
Data Com D8
Data Com D9
Line (multiplex section) DCC

Data Com D10 Data Com D11 Data Com D12 Sync S1 REI M0 Orderwi re E2
Page - 19
Trail Trace in SONET/SDH

87 Bytes
Trace J1
Path (HO-VC) trace J1

BIP-8 B3 label C2
status G1
Path Overhead
Synchronous Payload Envelop Capacity
9 rows
user F2
multi frame H4
Growth Z3
Growth Z4
Contains TCM layer trace and other items
Tandem N1
Page - 20
Trail Trace Summary

Primary usage
Detecting miss-connected signals at various layers in the transport hierarchy. Exists for Path (HO-VC), VT (LO-VC), TCM and Section layers and for most OTN layers. Conspicuously missing from Line (Multiplex Section) layer.
Operation
Trace text string (16 or 64 characters) is set via a management system. Expected trace (what you should be getting) is also set via a management system. Supervision is accomplished by enabling alarms if the expected trace doesnt match the received trace.
Current Use of Section Trace Bytes
Page - 22
J0-Based Neighbor Discovery via EMS

Compare
EMS
Report A, Z Values Report Z, A Values
A: TID, AID
Out-of-band Control
Z: TID, AID
Page - 23
Issues
The previous method dumps most of the work back to the EMS Doesnt necessarily blend with the rest of the control plane
How are the values of the traces filled in? May not work between domains (need some type of agreement, i.e., a standard!)
Doesnt work for the Line (multiplex section layer) since no trace
The line layer is very important since most ADM and high capacity cross connects work at this layer.
ITU-T G.7714.1 Discovery Protocol

Protocol for automatic discovery in SDH and OTN networks Use of Trail Trace
Specific encoding of trace string with (node, port) information. Node identification relevant to the control plane
Use of a DCC/GCC
For layers without trail trace a set of messages exchanged over the data communications channel (DCC) or General Communications Channel (GCC), that are part of the overhead for that layer.
Page - 25
G.7714.1 Discovery Mechanisms

SDH Mechanisms from G.7714.1 RS layer:
Within the RS layer, the J0 section trace and Section DCC may be used to support discovery of the RS TCP-to-TCP adjacency.
MS layer:
Within the MS layer, the Multiplex Section DCC may be used to support discovery of the MS TCP-to-TCP adjacency.
HOVC layer:
Within the HOVC layer, the higher order Path layer J1 trace may be used to support discovery of the HOVC TCP-to-TCP adjacency.
LOVC layer:
Within the LOVC layer, the lower order Path layer J2 trace may be used to support discovery of the LOVC TCP-to-TCP adjacency.
G.7714.1 Discovery Mechanisms

OTN Mechanisms from G.7714.1
OTUk layer:
Within the OTUk layer the SM section monitoring bytes and the GCC0 may be used to support discovery of the OTUk adjacency. Specifically, the SAPI subfield within the SM is used to carry the discovery message.
ODUk layer:
Within the ODUk layer the PM path monitoring bytes and the GCC-1 and GCC-2 bytes may be used to support discovery of the ODUk adjacency. Specifically, the SAPI subfield within the PM is used to carry the discovery message.
OTUk Frame Format

From G.709
Column Row 1 2 3 4 1 FA OH 7 8 14 15 OTUk OH
1
3824 3825
4080 SM
2 3
OTUk FEC (4 x 256 bytes)

0
TTI
BIP-8
1 2 3 4 5 6 7 8
SAPI
15 16
BEI
BDI IAE
RES
Column #
1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 31 32
DAPI GCC0 RES

TTI: BIP8: BEI: BDI: IAE: DAPI: SAPI: Trail Trace Identifier Bit Interleaved Parity - level 8 Backward Error Indication Backward Defect Indication Incoming Alignment Error Destination Access Point Identifier Source Access Point Identifier
FAS
FA: FAS: MFAS: SM: GCC: RES:
MFAS
SM
Frame Alignment Frame Alignment Signal MultiFrame Alignment Signal Section Monitoring General Communication Channel Reserved for future international standardisation
Operator Specific
63
Use the SAPI (source access point identifier) portion of the TTI (trail trace identifier) for G.7714.1 discovery.
ODUk Frame Format

Column Row 1 2 3 4
OPUk Overhead
PM and TCMi (i=1..6) 14 1516 17 3824

1 2 3
TTI
k DU O O d ea rh ve
1 2 3
BIP-8
OPUk Payload (4 x 3808 bytes)
SAPI
15 16
BEI
BDI
15 16
STAT
DAPI BIP8 Parity Block Column #

4 5 6 7 8 9 10 11 12 13 14 15 16 31 32
OPUk OH Operator Specific
1 2
Frame Alignment overhead RES TCM3 GCC1 GCC2 TCM ACT TCM2 APS/PCC TCM6 TCM5 TCM1
OTUk overhead TCM4 PM RES

0 1 63
Mapping specific
Row#
2 3 4
FTFL EXP
OPUk overhead
3 4
PSI
PT RES
PM: TCM: SAPI: DAPI: RES: ACT:
Path Monitoring Tandem Connection Monitoring Source Access Point Identifier Destination Access Point Identifier Reserved for future international standardisation Activation/deactivation control channel
FTFL: EXP: GCC: APS: PCC:
Fault Type & Fault Location reporting channel Experimental General Communication Channel Automatic Protection Switching coordination channel Protection Communication Control channel
TTI: BIP8: BEI: BDI: STAT: PSI: PT:
Trail Trace Identifier Bit Interleaved Parity - level 8 Backward Error Indication Backward Defect Indication Status Payload Structure Identifier Payload Type
255
Use the SAPI (source access point identifier) portion of the TTI (trail trace identifier) for G.7714.1 discovery.
G.7714.1 Information formats

Generally we need some type of node and port identifier. However this information may be shared in three different ways:
TCP Name Format

In this case a single identifier is used and can be resolved into the node and port ID via a name server. Keeps carrier network details completely hidden
DA DCN Address Format

In this case the node ID is the actual address of the control entity, known as the discovery agent, responsible for the discovery process. The port ID is also included.
G.7714.1 Information formats (cont.)

Generally we need some type of node and port identifier. However this information may be shared in three different ways:
DA DCN Name Format

In this case which is similar to the DA DCN Address format, the node name is given and can be resolved to the DA address via a name server. This format is useful when longer DCN addresses such as IPv6 format addresses are used. The port ID is also included.
Page - 31
G.7714.1 Discovery Message

Key design objective (accomplished)
One generic message format to be used for all different trail trace and DCC/GCC discovery processes. Compatibility with existing implementations
Implications
Message must fit into the severely space limited J0 section trace message. Total of 16 bytes. One byte used for CRC, One for distinguishing character, of remaining 14 bytes we can only use 7 out of 8 bits (compatibility with ITU-T T.50 character set). Additional compatibility requires the use of printable characters!
G.7714.1 Discovery Message Encoding

14 character slots (7 bit bytes restricted to printable characters) available IETF RFC 2045 base64 encoding
Maps 6 binary bits into a single printable character 14 Characters 6*14 = 84 bits available
Octet String (Hex) 0x11 0x23 0x45 0x67 0x8A 0xBC Binary String 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 1 0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 1 0 1 0 1 1 1 1 0 0 6-bit Decimal 4 18 13 5 25 56 42 60 Mapped Character E S N F Z 4 q 8

Page - 33
G.7714.1 Discovery Message Formats

TCP-ID Name Message format
0 0 0 1 0 2 0 3 1 4 5 6 7 8 9 1 0 1 2 3 4 2 5 6 7 8 9 0 TCP Name to look up 1 2 3 4 5 6 7 8 9 3 0 1
DA DCM Address Message format

0 0 0 1 0 2 1 3 0 4 5 6 1 9 0 1 2 3 4 DA DCN Context ID DA DCN Address cont'd Local TCP-ID cont'd 7 8 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 DA DCN Address Local TCP-ID 9 3 0 1
DA DCM Name Message format

0 0 0 1 0 2 1 3 1 4 5 6 7 8 9 1 0 1 2 3 4 2 5 6 7 8 9 0 1 Discovery Agent Name 2 3 4 5 6 7 8 9 3 0 1
Discovery Agent Name cont'd Local TCP-ID cont'd
Local TCP-ID
Page - 34
G.7714.1 procedures
For Trace based mechanism
Use the desired message format as the trace string.
For DCC/GCC mechanism

Choose either LAPD or PPP: LAPD use unnumbered information transfer (UIT) mode to send message. PPP use PPP LCP extension (RFC1570) packet type 12 (identification) with the message as the message!
Discovery Response Message

May be sent specifying the node and port that just received the sent message. How this is done is not currently specified in G.7714.1
OIF UNI 1.0/1.1 Discovery

DCC based
Uses either line (multiplex section) or section (regenerator section) data communications channel (DCC)
Uses IETF LMP message Format

This usage is not specified in the IETFs Link Management Protocol (LMP), but is specified in the UNI1.0/1.1 documents available without charge at www.oiforum.com
OIF UNI modified LMP Config Procedure

Config Config Ack/Nack
Node ID
CCID Message ID Messages sent over each control channel
Config Objects
Config Message Node ID: Sending Node ID; CCID: Port number Msg ID: Unique ID assigned by sending node Hello Interval Hello Dead Interval Hello Config Object Hello Int. : Frequency of Hello messages; Hello Dead Int.: Waiting time before declaring neighbor dead
Verifying Port Connectivity

Config (Node ID = 192.28.134.2 , CCID = 1)
T R
R T
ConfigAck (Node ID = 198.28.134.5, CCID = 4, Recd. Node ID = 192.28.134.2, Rcv. CC ID = 1) Config (Node ID = 192.28.134.2 , CCID = 3)
T R
R T
Client
ConfigAck (Node ID = 198.28.134.5, CC ID = 6, Recd. Node ID = 192.28.134.2, Rcv. CC ID = 3)
OXC
Node ID = 192.28.134.2
Node ID = 192.28.134.5
Page - 38
Detecting Incorrect Wiring

N1 (192.14.15.2)
1 T R 2 T R
N2 (192.15.2.3)
T R T R 11 10 Config (N1, msg=1, ccid=1) Config (N1, msg=2, ccid=2) Exchanges at Ack (N2,ccid = 10, msg=2, N1, N1,P1 and N1,P2 rccid=2) Ack (N2,ccid = 11, msg=1, N1, rccid=1)
T
3 R
T R
12
Page - 39
Physical Media Adjacency Discovery

Whos my physical neighbor?
Currently no standards but there has been some good work in this area.
Simple Optical Neighbor Discovery (SOND)

Idea: create low speed communications channel at link turn up for sending/receiving discovery information Uses the Laser Shutdown (LS) signal to transmit information and the Loss of Signal (LOS) indication to receive information. Reference: Stefan N. Larsson, Sten Hubendick, and Robert
Nedelchef, Wavium AB, Simple optical neighbor discovery (SOND): architecture, applications, and experimental verification,October 2003, Journal of Optical Networking.
Page - 40
Control Entity Adjacency Establishment

Concept: separation of control and data plane
Control traffic does not run over the data plane Link overhead may furnish part of the control plane network.
IP Network
IPd IPb
LTE or PXC
LTE or PXC
IPc
IPa
Data Plane
Control Plane
Page - 41
IP Network
Control Entity Adjacency Establishment

How do we find out who our neighbor control entity is? (at a given layer)
Provision this information Obtain this information via layer adjacency discovery, I.e., the DCN address is the address of the control entity.
How do we establish and maintain the communications channel between these entities?
The IETFs Link Management Protocol (LMP) has procedures for Control Channel Management In does this via a Config procedure which verifies bidirectional connectivity and a heartbeat procedure (named Hello) to monitor connectivity.
LMP Messages
LMP messages run over UDP (User Datagram Protocol)
Control Channel Management Messages Link Property Correlation Messages Link Verification Messages (optional not really needed for SDH/OTN) Fault Management Messages (optional not really needed for SDH/OTN)
Two flags: Control channel down, and LMP restart
Version # (Reserved) LMP Length Flags (Reserved) Msg Type
Type 1 2 3 4 5
Message Config ConfigAck ConfigNack Hello BeginVerify
Type 6 7 8 9 10
Message BeginVerifyAck BeginVerifyNack EndVerify EndVerifyAck Test
Type 11 12 13 14 15
Message TestStatusSuccess TestStatusFailure TestStatusAck LinkSummary LinkSummaryAck
Type 16 17 18 19 20
Message LinkSummaryNack ChannelStatus ChannelStatusAck ChannelStatusRequest ChannelStatusRespons
Page - 43
LMP Objects
LMP Messages consist of LMP Objects of the following form
N indicates whether the object is negotiable C-Type is the generic class type of the object Class is the particular type of object, e.g., an IPv4 address versus an IPv6 address
N
C-Type
Class
Length
(object contents)
Page - 44
LMP Link Management Messages

Config Message (starts the conversation rolling)
::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> <LOCAL_NODE_ID> <CONFIG>
ConfigAck Message (used to establish two way connectivity)

::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID><REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
ConfigNack Message
::= <Common Header> <LOCAL_CCID><LOCAL_NODE_ID> <REMOTE_CCID><MESSAGE_ID_ACK><REMOTE_NODE_ID > <CONFIG>
Hello Message (used as a heartbeat)

::= <Common Header> <LOCAL_CCID> <HELLO>
Page - 45
LMP Link Summary Messages

LinkSummary Message
::= <Common Header> <MESSAGE_ID> <TE_LINK> <DATA_LINK> [<DATA_LINK>...]
LinkSummaryAck Message
::= <Common Header> <MESSAGE_ID_ACK>
LinkSummaryNack Message
::= <Common Header> <MESSAGE_ID_ACK><ERROR_CODE> [<DATA_LINK>...]
Page - 46
LMP Functions
Conceptual control channel created and maintained via LMP config and hello messages.
IP Network
IPa Control for A
IPb Control for B
Conceptual TE link, a bundle of real links agreed upon via LMP summary messages.
Discovery Summary
Which layer should I discover?
Generally rule: all layers that you process. Most important for layers that you switch at.
What functionality do I want?

Automatic inventory of links
Uni-directional as in G.7714.1
Bi-directional wiring verification

Extra procedure in G.7714.1 may use some LMP messages
Bootstrap G.ASON/GMPLS control plane

Bring up control channel Bundle parallel lines into TE links for representation in routing protocols.
Status
Interoperability
No significant demonstration of neighbor discovery interoperability yet But standardization of G.7714.1 should help.
Deployment
A variety of proprietary implementations typically tied to link state protocols running over line or section DCC are being used in production transport networks Integration with existing OSS

GMPLS Discovery

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GMPLS Discovery

Uploaded by

Copyright:

Available Formats

Discovery

Grotto Networking 2004

Control Plane Discovery

Confirmed that Mr. Blue has got my name right.

Grotto Networking 2004

But is it worth the effort?

Grotto Networking 2004

Neighbor Discovery (Why bother?)

Edge Equipment #2 Edge Equipment #N Edge Equipment #N Edge Equipment #N

256 ports of OC-48

Edge Equipment #N Edge Equipment #N Edge Equipment #N

Inconsistent Wiring Issues

Grotto Networking 2004

Inconsistent Wiring Problems

Grotto Networking 2004

Why do Neighbor Discovery?

Allows automatic identification of nodepair neighbors

Grotto Networking 2004

Existing Neighbor Discovery Protocols

Grotto Networking 2004

OSPFs Hello Protocol

OSPF Hello packet is carried in an IP datagram

Grotto Networking 2004

OSPFs Hello Protocol

Hello Received Hello Received

Ive received a hello but dont know if they know me.

Init 1-Way Received 2-Way Received

I know them and they know me.

Grotto Networking 2004

A Solution Exists, can we go home?

Separation of Control and Data Planes

Grotto Networking 2004

Layers in WDM Networks

Grotto Networking 2004

Layers in TDM Networks

Grotto Networking 2004

J2 VT trace J1 Path trace

STS Path Tandem Connection (optional) Line

No Line trace J0 section trace

Line Section Section

Grotto Networking 2004

Neighbor Discovery at which layer?

LTE-LTE neighbor discovery

PLR-PLR neighbor discovery

Generalized Automatic Discovery

Physical Media Adjacency Discovery Data Plane

Control Entity Logical Adjacency Establishment Service Capability Exchange

Layer Adjacency Discovery

Grotto Networking 2004

Trail Trace in SONET/SDH

Section (regenerator section) trace J0

Poi nter Ac tion H3

Line (multiplex section) DCC

Grotto Networking 2004

Trail Trace in SONET/SDH

Path (HO-VC) trace J1

Synchronous Payload Envelop Capacity

Contains TCM layer trace and other items

Grotto Networking 2004

Trail Trace Summary

Current Use of Section Trace Bytes

J0-Based Neighbor Discovery via EMS

Grotto Networking 2004