Sie sind auf Seite 1von 49

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

Grotto Networking 2004

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

Grotto Networking 2004

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


Page - 5 Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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
Page - 16 Grotto Networking 2004

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?
Page - 17 Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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.
Page - 21 Grotto Networking 2004

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

Grotto Networking 2004

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.
Page - 24 Grotto Networking 2004

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

Grotto Networking 2004

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.
Page - 26 Grotto Networking 2004

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.
Page - 27 Grotto Networking 2004

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.
Page - 28 Grotto Networking 2004

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.
Page - 29 Grotto Networking 2004

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.
Page - 30 Grotto Networking 2004

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

Grotto Networking 2004

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!
Page - 32 Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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
Page - 35 Grotto Networking 2004

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
Page - 36 Grotto Networking 2004

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
Page - 37 Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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
Grotto Networking 2004

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.
Page - 42 Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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

Grotto Networking 2004

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.
Page - 47 Grotto Networking 2004

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.
Page - 48 Grotto Networking 2004

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
Page - 49 Grotto Networking 2004