GMPLS Discovery

7/28/2019 GMPLS Discovery

1/49

Page - 1 Grotto Networking 2004

Discovery


2/49


Neighbor Discovery

Motivations and previous approaches

Data Plane Discovery

Functionality

OIF UNI Discovery

G.7714.1 Discovery

Control Plane Discovery

Functionality

GMPLS LMP


3/49


Discovery Motivation

Who is on the other side of the link? Analogy: The human hello protocol

Hello, Im Mr. Blue

Hi, Mr. Blue, Im Ms.

Orange

Nice to meet you Ms.

Orange.

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

Its Mr. Blue. Lets tell him who

I am and check his name.

Confirmed that Mr. Blue has

got my name right.


4/49


But is it worth the effort?

Early days of optical networking very few fibersand no standard protocols for this function No.

Current technology lots of fibers Yes!

With commerciallyavailable modern

DWDM systems, one

long-haul fiber pair can

contain more than 100

channels, which get

broken out intoindividual fiber pairs at

end systems and

regenerators.


5/49


OC-48 lines

OC-48 lines

Edge Equipment #1

Edge Equipment #2

Edge Equipment #N

Edge Equipment #N

Edge Equipment #N

Edge Equipment #N

Edge Equipment #N

Edge Equipment #N

Neighbor Discovery (Why bother?)

A single box can have lots of neighbors! Modern SONET/SDH and WDM equipment

can support many ports!

256 ports of OC-48


6/49


Inconsistent Wiring Issues

Consider a bidirectional 1+1 fiber pairWorks fine under normal conditions

Works fine if we lose a fiber, 1+1 protection.

Maintenance operation: Replace bad fiber

Box A Box B

Port 1

Port 2

Port 12

Port 13

Conduit


7/49


Inconsistent Wiring Problems

Undetected miss-wiringBig problem we just pulled the wrong fiber!!!

Now Box A cant hear from Box B.

Box A Box B

Port 1

Port 2

Port 12

Port 13


8/49


Why do Neighbor Discovery?

Allows automatic inventory of physicallinks between nodes

Can determine inconsistent physical wiring

Allows automatic identification of node-pair neighbors

Supports accurate neighbor link information

for use in routing and signaling


9/49


Existing Neighbor Discovery Protocols

A subclass of IP routing protocols contain ahello 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
http://www.ietf.org/http://www.ietf.org/


10/49


OSPFs Hello Protocol

Neighbor Discovery (bi-directional communications)

Designated Router Election for LANs

Dead Router Detection

OSPF Hello

packet is

carried in an

IP datagram

Version # Type = 1 (hello) Packet length

Router ID

Area ID

Checksum AuType

Authentication

Authentication

Network Mask

HelloInterval (in seconds) Options Rtr Pri

RouterDeadInterval (in seconds)

Designated Router

Backup Designated Router

Neighbor Router ID


11/49


OSPFs Hello Protocol

Neighbor State Machine

Down Attempt

Init 2-Way

Start

Hello Received

Hello Received

1-Way Received

2-Way Received

Keep saying hellountil something

happens...

Ive received ahello but dontknow if they

know me.

I know them and

they know me.


12/49


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 thequestion a bit more complicated.

Separation of Control and Data Planes

Further complicates things and gives us more todiscover


13/49


Layers in WDM Networks

Optical

Amplifier #1

Optical

Amplifier #2

Optical Add/

Drop

multiplexor

Optical

Multiplexor

Optical De-

multiplexor

= Optical Fiber

= Optical Support Channel

for Transport layer

= Optical Support Channel

for multiplex layer

OCh

OMS

OTS OTS OTS

OCh

OMS

OTS

OCh

OMS

OTS

Optical Channel

Optical Multiplex

SectionOptical Transport

Section


14/49


Layers in TDM Networks

Regenerator

(3R) #1

Regenerator

(3R) #2

TDM de-

multiplexor

TDM

Multiplexor

= Optical Fiber

= Regenerator section overhead

= Multiplex section (line) overhead

= User traffic (path layer)

= Unused time slots

Path

MS

RS RS RS

Path

MS

RS

TDM Path

Multiplex Section

Regenerator

Section


15/49


SONET/SDH Layers

PTE TCTE LTE LTE TCTE PTESTE STE

Section Section Section Section Section Section Section

Line LineLine LineLine

Tandem Connection

(optional)

STS Path

VT Path

STS Path

Tandem Connection

(optional)

Line

Section

Physical

Lower order

Virtual Containers

Higher order

Virtual Containers

Tandem Connection

(optional)

Multiplex Section

Regenerator Section

Physical

(a) SONET (b) SDH

50Mbps 40Gbps

1.5Mbps 6Mbps

Multiplexing here

J0 section trace

J1 Path traceMultiplexing here

J2 VT trace

No Line trace


16/49


Neighbor Discovery at which layer?

PLR PLR STE LTE PTESTELTEPTE

STE-STE neighbor discovery

LTE-LTE neighbor discovery

PLR-PLR neighbor discoveryDefinitions

PLR - Physical Layer Regenerator

STE - Section Terminating Equipment

LTE - Line Terminating Equipment

PTE - Path Terminating Equipment

STE-STE neighbor discoveryPLR-PLR neighbor discovery


17/49


Generalized Automatic Discovery

Layer Adjacency Discovery

Who are my neighbor peers?

Physical Media Adjacency Discovery

What is the next box Im physically connected to? Control Entity Logical Adjacency

Establishment

If we are going to participate in a control protocol

who should I talk to? Service Capability Exchange

What kinds of things can your peer box orsubnetwork do? How are you configured?

ITU G.7714 ConceptsData Plane

Data Plane

Control Plane

Control Plane


18/49


Layer Adjacency Discovery

Who is my peer at a particular layer in thetransport system.

Similar to the connectivity supervision

management taskAnswers the question:Am I connected to the

right end point?

Usually continuously monitored General mechanism for this is a trail trace


19/49


Trail Trace in SONET/SDH

FramingA1

FramingA2

TraceJ0

BIP-8B1

OrderwireE1

UserF1

Data ComD1

Data ComD2

Data ComD3

PointerH1

PointerH2

PointerAc tio n

H3

BIP-8B2

AP SK1

AP SK2

Data ComD4

Data ComD5

Data ComD6

Data ComD7

Data ComD8

Data ComD9

Data ComD10

Data ComD11

Data ComD12

SyncS1

REIM0

OrderwireE2

SectionOverhead

LineOverhead

9 rows

90 By tes

Sy nchronous Pay loadEnvelop

Section (regenerator

section) trace J0

Section DCC

Line (multiplex section) DCC


20/49


Trace

J1

BIP-8

B3

label

C2

status

G1

user

F2

multi

frame

H4

Growth

Z3

Growth

Z4

Tandem

N1

Path

Overhead

9 rows

87

Bytes

Synchronous Payload

Envelop Capacity

Trail Trace in SONET/SDH

Path (HO-VC) trace J1

Contains TCM layer

trace and other items


21/49


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 OTNlayers. Conspicuously missing from Line (MultiplexSection) layer.

Operation

Trace text string (16 or 64 characters) is set via amanagement system.

Expected trace (what you should be getting) is also setvia a management system.

Supervision is accomplished by enabling alarms if theexpected trace doesnt match the received trace.


22/49

Page - 22

Current Use of Section Trace Bytes


23/49


J0-Based Neighbor Discovery via EMS

A: TID, AID

Z: TID, AID

EMSReport A, Z Values

Report Z, A Values

Compare

Out-of-band

Control


24/49


Issues

The previous method dumps most of the workback to the EMS

Doesnt necessarily blend with the rest of thecontrol 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.


25/49


ITU-T G.7714.1 Discovery Protocol

Protocol for automatic discovery in SDH andOTN 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.


26/49


G.7714.1 Discovery Mechanisms

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.

SDH Mechanisms from G.7714.1


27/49


G.7714.1 Discovery Mechanisms

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 tosupport discovery of the ODUk adjacency. Specifically,

the SAPI subfield within the PM is used to carry the

discovery message.

OTN Mechanisms from G.7714.1


28/49


OTUk Frame Format

From G.709

Use the SAPI (source access point identi f ier) por tion

of the TTI (trail tr ace identi f ier) for G.7714.1

discovery.

TTI BIP-8

BEIBDI

RES

1 2 3 4 5 6 7 8

1 2 3

SM1

2

3

4

1 14 15 3824Row

Column

OTUk OH

3825 4080

OTUk FEC(4 x 256 bytes)

FA: Frame AlignmentFAS: Frame Alignment SignalMFAS: MultiFrame Alignment SignalSM: Section MonitoringGCC: General Communication ChannelRES: Reserved for future international standardisation

1

1 2 3 4 5 6 7 8

FAS

Column #

MFAS SM

9 10 11 12 13 14

RESGCC0

TTI: Trail Trace IdentifierBIP8: Bit Interleaved Parity - level 8BEI: Backward Error Indication

BDI: Backward Defect IndicationIAE: Incoming Alignment ErrorDAPI: Destination Access Point IdentifierSAPI: Source Access Point Identifier

IAE

FA OH

7 8

63

32

0

1516

31

SAPI

DAPI

OperatorSpecific


29/49


ODUk Frame Format

1

2

3

4

1 2 3 4 5 6 7 8

Frame Alignment overhead

Column #

RESOPUk

overhead

OTUk overhead

9 10 11 12 13 14 15 16

Row#

EXP

TCM

ACTTCM5 TCM4

TCM3 TCM2 TCM1

TCM6

GCC1 GCC2

FTFL

PM

RES

1

2

3

4

1 16 17 3824Row

Column

ODUkO

verhead

OPUk Payload(4 x 3808 bytes)

PM: Path Monitoring

TCM: Tandem Connection MonitoringSAPI: Source Access Point Identifier

DAPI: Destination Access Point Identifier

RES: Reserved for future international standardisationACT: Activation/deactivation control channel

BIP8 Parity Block

1514

OPUk

Overhead

APS/PCC

63

TTI BIP-8

32

0

1516

BEIBDI

STAT

1 2 3 4 5 6 7 8

1 2 3

PM and TCMi (i=1..6)

FTFL: Fault Type & Fault Location reporting channel

EXP: ExperimentalGCC: General Communication Channel

APS: Automatic Protection Switching coordination channel

PCC: Protection Communication Control channel

TTI: Trail Trace Identifier

BIP8: Bit Interleaved Parity - level 8BEI: Backward Error Indication

BDI: Backward Defect Indication

STAT: StatusPSI: Payload Structure Identifier

PT: Payload Type

PSI

Mappingspecific

OPUk OH

15 16

1

2

3

4

RES

255

0

1

PT

31

SAPI

DAPI

Operator

Specific

Use the SAPI (source access point identi f ier) por tion of

the TTI (trail trace identi f ier) for G.7714.1 discovery.


30/49


G.7714.1 Information formats

TCP Name Format

In this case a single identifier is used and can beresolved into the node and port ID via a nameserver. Keeps carrier network detailscompletely hidden

DA DCN Address Format

In this case the node ID is the actual address ofthe control entity, known as the discoveryagent, responsible for the discovery process.The port ID is also included.

General ly we need som e type of node and port ident i f ier. However this

inform at ion may be shared in three dif ferent ways:


31/49


G.7714.1 Information formats (cont.)

DA DCN Name Format

In this case which is similar to the DA DCN

Address format, the node name is given and canbe 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.

General ly we need som e type of node and port ident i f ier. However this

inform at ion may be shared in three dif ferent ways:


32/49


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 fordistinguishing character, of remaining 14 bytes we canonly use 7 out of 8 bits (compatibility with ITU-T T.50character set). Additional compatibility requires the useof printable characters!


33/49


G.7714.1 Discovery Message Encoding

14 character slots (7 bit bytes restricted toprintable characters) available

IETF RFC 2045 base64 encoding

Maps 6 binary bits into a single printablecharacter

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


34/49


G.7714.1 Discovery Message Formats

0

0 1 2 3 4 5 6 7 8 9

1

0 1 2 3 4 5 6 7 8 9

2

0 1 2 3 4 5 6 7 8 9

3

0 1

0 0 1 0 DA DCN Context ID DA DCN Address

DA DCN Address cont'd Local TCP-ID

Local TCP-ID cont'd

00 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1

0 0 1 1 Discovery Agent Name

Discovery Agent Name cont'd Local TCP-ID

Local TCP-ID cont'd

0

0 1 2 3 4 5 6 7 8 9

1

0 1 2 3 4 5 6 7 8 9

2

0 1 2 3 4 5 6 7 8 9

3

0 1

0 0 0 1 TCP Name to look up

TCP-ID Name Message format

DA DCM Address Message format

DA DCM Name Message format


35/49


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 notcurrently specified in G.7714.1


36/49


OIF UNI 1.0/1.1 Discovery

DCC basedUses 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
http://www.oiforum.com/http://www.oiforum.com/


37/49


OIF UNI modified LMP Config

Procedure

Config

Config Ack/Nack

Node ID Message ID Config Objects

Config Message

Hello Interval Hello Dead Interval

Hello Config Object

Node ID: Sending Node ID; CCID: Port number Msg ID: Unique ID assigned

by sending node

Hello Int. : Frequency of Hello messages;

Hello Dead Int.: Waiting time before declaring neighbor dead

Messages sentover each control

channel

CCID


38/49


Verifying Port Connectivity

Node ID =

192.28.134.5

OXC

T

R

T

R

R

T

R

T

Config (Node ID = 192.28.134.2 , CCID = 1)

1

3

4

6

ConfigAck (Node ID = 198.28.134.5, CCID = 4,

Recd. Node ID = 192.28.134.2, Rcv. CC ID = 1)

Node ID =

192.28.134.2

Client

Config (Node ID = 192.28.134.2 , CCID = 3)

ConfigAck (Node ID = 198.28.134.5, CC ID = 6,

Recd. Node ID = 192.28.134.2, Rcv. CC ID = 3)


39/49


Detecting Incorrect Wiring

T T

T

TT

R R

R R

R R

T

1

2

3

10

11

12

N1 (192.14.15.2) N2 (192.15.2.3)

Config (N1, msg=1, ccid=1)

Ack (N2,ccid = 10, msg=2, N1,

rccid=2)

Exchanges at

N1,P1 and N1,P2

Config (N1, msg=2, ccid=2)

Ack (N2,ccid = 11, msg=1, N1,

rccid=1)


40/49


Physical Media Adjacency Discovery

Whos my physical neighbor?

Currently no standards but there has been some goodwork 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 toreceive information.

Reference: Stefan N. Larsson, Sten Hubendick, and RobertNedelchef, Wavium AB, Simple optical neighbor discovery(SOND): architecture, applications, and experimentalverification,October 2003, Journal of Optical Networking.


41/49


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

IP Network

IP Network

IPa

IPb

IPc

IPd

LTE or

PXC

LTE or

PXC

Data

Plane

Control

Plane


42/49


Control Entity Adjacency Establishment

How do we find out who our neighbor control entityis? (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 thecommunications channel between these entities?

The IETFs Link Management Protocol (LMP) has

procedures forControl Channel Management In does this via a Configprocedure which verifies

bidirectional connectivity and a heartbeat procedure(namedHello) to monitor connectivity.


43/49


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 forSDH/OTN)

Version # (Reserved)

LMP Length (Reserved)

Flags Msg Type

Type Message

1 Config

2 ConfigAck

3 ConfigNack

4 Hello

5 BeginVerify

Type Message

6 BeginVerifyAck

7 BeginVerifyNack

8 EndVerify

9 EndVerifyAck

10 Test

Type Message

11 TestStatusSuccess

12 TestStatusFailure

13 TestStatusAck

14 LinkSummary

15 LinkSummaryAck

Type Message

16 LinkSummaryNack

17 ChannelStatus

18 ChannelStatusAck

19 ChannelStatusRequest

20 ChannelStatusRespons

Two flags: Control channel down, and LMP restart


44/49


LMP Objects

LMP Messages consist of LMP Objects ofthe following form

N indicates whether the object is negotiable

C-Type is the generic class type of the objectClass is the particular type of object, e.g., an

IPv4 address versus an IPv6 address

N

C-Type

(object contents)

LengthClass


45/49


LMP Link Management Messages

Config Message (starts the conversation rolling) ::=

ConfigAck Message (used to establish two way connectivity)

::=

ConfigNack Message

::= Hello Message (used as a heartbeat)

::=


46/49


LMP Link Summary Messages

LinkSummary Message ::=

[...]

LinkSummaryAck Message

::=

LinkSummaryNack Message

::=

[...]


47/49


LMP Functions

IP Network

IPa IPb

Control

for A

Control

for B

Conceptual control channelcreated and maintained via LMP

config and hello messages.

Conceptual TE link, a bundle of

real links agreed upon via LMP

summary messages.


48/49


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


49/49

Status

InteroperabilityNo significant demonstration of neighbor

discovery interoperability yet

But standardization of G.7714.1 should help.

Deployment

A variety of proprietary implementationstypically tied to link state protocols running

over line or section DCC are being used inproduction transport networks

Integration with existing OSS

GMPLS Discovery

Documents

Transcript of GMPLS Discovery