Optical Networking Standardization in OIF, IETF and ODSI
Download
Report
Transcript Optical Networking Standardization in OIF, IETF and ODSI
Introduction to Optical Control Plane
Technology and Standards
Greg Bernstein
Grotto Networking
[email protected]
Grotto
Page - 1
Networking
© Grotto Networking 2004
Bala Rajagopalan
[email protected]
Outline
• Overview of Optical Network Control
• Discovery
• Switching Types
• Signaling
• Topology and Resource Status
Dissemination (Routing)
• Path Computation
• Applications of GMPLS/G.ASON
Grotto
Page - 2
Networking
© Grotto Networking 2004
Optical Network Control and
Management Overview
•
•
•
•
•
•
Motivation
Network structure
Managing optical networks
Additional desired functionality
Relation between management and control
Standards bodies and their roles
Grotto
Page - 3
Networking
© Grotto Networking 2004
Motivation
• The purpose of the management and control
systems for optical networks is to provide
for the efficient delivery of highly available,
highly reliable communication services.
• These services consist of a variety of
different types of connections between end
users of the optical network.
Grotto
Page - 4
Networking
© Grotto Networking 2004
Network Structure and Terminology
C3
C9
Node or
Network Element (NE)
C2
C4
C10
C1
End
system
A
C8
C6
C7
B3
B2
Subnetwork C
B4
B1
Link
B7
Network
Grotto
Page - 5
Networking
B8
B6
© Grotto Networking 2004
Subnetwork B
End
system
Z
Connection Structure and Terminology
C3
C9
Link Connection
C2
C4
End
system
A
Subnetwork
connection
C10
C1
C8
C6
C7
B3
B2
Subnetwork
connection
B4
B1
B8
B6
B7
Network connection
Grotto
Page - 6
Networking
© Grotto Networking 2004
End
system
Z
Basic Management Questions
• How do we know if we are receiving a good
signal?
• How do we know if we are receiving the right
signal?
• What should I send downstream if I don’t receive
a good signal?
• How do I know if the receiver can hear me?
• How well can they hear me?
Grotto
Page - 7
Networking
© Grotto Networking 2004
Basic Management Questions
• What’s the bit error rate of the received signal?
• In what part of the network did these errors occur?
• How can I control the switch over to a redundant
transport resource in a timely manner?
• How can I communicate with remote equipment
for management and control purposes?
• What kind of payload is being carried in this
signal?
Grotto
Page - 8
Networking
© Grotto Networking 2004
SONET’s Embedded Management Functionality
Questions
How do we know if we are receiving a good
signal?
How do we know if we are receiving the
right signal
What should I send downstream if I don’t
receive a good signal?
SONET
Management
capability
Continuity
supervision
Loss of Frame detection
Connectivity
supervision
Section and Path trace strings
Maintenance
information
Alarm Indication Signal (AIS)
Remote defect indication (RDI)
Remote Error Indication (REI)
Performance monitoring:
Section, Line and Path bit
interleaved parity (BIP) error
detection bytes.
Tandem connection monitoring
How do I know if the receiver can hear me?
Mechanism or Process
How well can they hear me?
What’s the bit error rate of the received
signal?
Signal quality
supervision
In what part of the network did these errors
occur?
How can I control switch over to redundant
transport systems in a timely manner.
Protection
control
Line layer protection via K1/K2
bytes
Automatic protection switching
protocol for linear and ring
protection.
How can I communicate with remote
equipment for management and control
purposes?
Grotto
Page - 9
Networking
Management
communications
© Grotto Networking 2004
Reserving part of an optical
support channel for
management and control
communications.
OTN’s Embedded Management Functionality
Questions
How do we know if we are receiving a good
signal?
How do we know if we are receiving the right
signal
What should I send downstream if I don’t
receive a good signal?
OTN
Management
capability
Continuity
supervision
Loss of continuity detection
Connectivity
supervision
Trail trace identification
Maintenance
information
Forward defect indication
Backward defect indication
Backward quality
indication
Performance monitoring
Tandem connection
monitoring
Protection
control
Automatic protection
switching protocol
Management
communications
Reserving part of an optical
support channel for
management and control
communications.
How do I know if the receiver can hear me?
Mechanism or Process
How well can they hear me?
What’s the bit error rate of the received signal?
Signal quality
supervision
In what part of the network did these errors
occur?
How can I control switch over to redundant
transport systems in a timely manner.
How can I communicate with remote
equipment for management and control
purposes?
Grotto
Page - 10
Networking
© Grotto Networking 2004
How do we manage all this?
Divide and Conquer!
• Multiple layers of management
– Management functionality in each network
element and support on each communications
link
– Element management system (EMS): Manages
a subnetwork of the network elements
– Network management system (NMS): talks to
the EMSs to get the overall view of the
network.
Grotto
Page - 11
Networking
© Grotto Networking 2004
Layered Network Management
NMS
Core
EMS
O3
EMS 1
O9
O2
EMS 2
O4
O10
O1
O8
O6
M5
O7
M4
M1
M2
Core Network
M6
M3
Metro SubNetwork 2
Metro SubNetwork 1
Grotto
Page - 12
Networking
© Grotto Networking 2004
A few unanswered questions…
• How do I know who is on the other end of a
link? How do I talk to them for control
purposes?
• How do I know what equipment is in my
network? (Links and switching nodes)
• How do I control (set up and tear down) lots
of connections efficiently?
Previously manually configured!
Grotto
Page - 13
Networking
© Grotto Networking 2004
Optical Network Control Processes
For our unanswered questions…
Inventory & Resource Management
2. Global Topology Dissemination
1. Neighbor Discovery
NETWORK
MGMT PLANE
User
User
OUNI
CONTROL PLANE
DATA PLANE
3. Connection Request
4. Path Calculation (NE-based or EMS-based)
Dynamic Provisioning
Grotto
Page - 14
Networking
5. Establish Connection
© Grotto Networking 2004
Control Plane Components
• Automatic Neighbor Discovery
– Allows a node to determine the identity of each
neighboring node and the set of links that
connect them.
• Topology and resource status dissemination
– Allows every node to automatically discover
the complete network topology and resources
• Signaling for Connection Provisioning
– Allows the establishment and teardown of a
path from one end of the connection
Grotto
Page - 15
Networking
© Grotto Networking 2004
Management and control
• Management systems have significant
functionality not addressed in the control
plane
– For example performance monitoring
• New control plane functionality
supplements but does not replace important
management functions.
– Management systems can make use of
discovered neighbor and topology information
– Parts of connection processing can be off
loaded to the control system.
Grotto
Page - 16
Networking
© Grotto Networking 2004
Overview of Control Plane
Technology Standards
Grotto
Page - 17
Networking
© Grotto Networking 2004
Standards Bodies and Organizations
Charter: Global Telecom Architecture and
Standards
Member Organizations:
• Global Service Providers
• PTTs, ILECs, IXCs
• Telecom equipment vendors
• Governments
Charter: Evolution of the
Internet (IP) Architecture
Charter: Development of Optical
Networking Products and Services
Active Participants:
• ISPs
• Service Provider IP Divisions
• IP/Ethernet Vendors
Member Organizations:
• PTTs, ISPs, ILECs, IXCs
• Optical Networking Vendors
Grotto
Page - 18
Networking
Charter: Network Management
Over 350 members including
• Service providers
• Equipment vendors
• Software vendors
© Grotto Networking 2004
ITU-T
International Telecommunications Union – Telecommunications Sector
• Architecture, Requirements, Models
• G.807: Requirements for ASTN
• G.8080: ASON Architecture
• G.7712: Data Communication Network Arch.
• Discovery
• G.7714: General process and model
• G.7714.1: Discovery for SONET/SDH and OTN
• Signaling:
• G.7713: Distributed Connection Management model
• G.7713.1, G.7713.2, G.7713.3 Signaling protocols
• Routing
Grotto
Page - 19
Networking
• G.7715: Routing architecture and requirements
• G.7715.1: Link state routing requirements
© Grotto Networking 2004
IETF
Internet Engineering Task Force
• Architecture
– GMPLS Architecture (draft)
– Generalized Multi-Protocol Label Switching
Extensions for SONET and SDH Control
• Link Management
– Link Management Protocol (draft)
• Signaling
• RFC 3471: GMPLS Signaling Functional Spec.
• RFC 3473: GMPLS-RSVP-TE
• RFC 3472: GMPLS-CR-LDP
• Routing
• GMPLS extensions for OSPF-TE (draft)
Grotto
Page - 20
Networking
© Grotto Networking 2004
OIF
Optical Internetworking Forum
• Signaling/Interface Standards
–
–
–
–
UNI version 1.0 release 2
External intra-carrier NNI 1.0 (signaling)
Security specifications for the above.
In progress routing
• Interoperability Events!
• Physical Layer Standards
– A very successful set of inter-chip
specifications (not in our scope here).
Grotto
Page - 21
Networking
© Grotto Networking 2004
TMF
TeleManagement Forum
• An number of activities beyond our scope…
• MTNM (Multi Technology Network
Management)
– Business Agreement - TMF513 (requirements)
– Information Agreement - TMF608 (management
technology independent info models)
– Solution Sets - TMF814 (CORBA), XML to come
– Currently working on management of control plane
Grotto
Page - 22
Networking
© Grotto Networking 2004
Some Prerequisites
• “Data Communication Network” (DCN)
– A means for the nodes to communicate for executing
control and management protocols
– Maybe a completely separate communications network,
use SONET/SDH/OTN overhead channels, or a
combination of the two…
• Administrative Framework
– Uniform addressing scheme for controlled entities
– Policy enforcement pertaining to provisioning and
restoration
Grotto
Page - 23
Networking
© Grotto Networking 2004
Discovery
Grotto
Page - 24
Networking
© Grotto Networking 2004
Neighbor Discovery
• Motivations and previous approaches
• Layers in Transport networks
• Generalized Automatic Discovery
–
–
–
–
Layer Adjacency
Management concept: trail trace
G.7714.1 Discovery
OIF UNI 1.0 example
• Control Plane “Discovery”
– Functionality
– GMPLS’ LMP
Grotto
Page - 25
Networking
© 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…
Hello, I’m Mr. Blue
It’s Ms. Orange
and she got my
name right.
Let me double
check that I got
her name right
Grotto
Page - 26
Networking
It’s Mr. Blue. Let’s tell him who
I am and check his name.
Hi, Mr. Blue, I’m Ms.
Orange
Nice to meet you Ms.
Orange.
© Grotto Networking 2004
Confirmed that Mr. Blue has
got my name right.
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.
Grotto
Page - 27
Networking
© 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
Edge Equipment #2
OC-48 lines
Edge Equipment #N
Edge Equipment #N
Edge Equipment #N
OC-48 lines
256 ports of OC-48
Grotto
Page - 28
Networking
© 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 2
Grotto
Page - 29
Networking
Box A
Port 12
Conduit
Port 13
© Grotto Networking 2004
Box B
Inconsistent Wiring Problems
• Undetected miss-wiring
– Big problem we just pulled the wrong fiber!!!
Now Box A can’t hear from Box B.
Port 1
Port 12
Port 13
Port 2
Grotto
Page - 30
Networking
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
Grotto
Page - 31
Networking
© 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
Grotto
Page - 32
Networking
© Grotto Networking 2004
OSPF’s Hello Protocol
• Neighbor Discovery (bi-directional communications)
• Designated Router Election for LANs
• Dead Router Detection
Version #
Type = 1 (hello)
Packet length
Router ID
Area ID
Checksum
AuType
Authentication
Authentication
Network Mask
HelloInterval (in seconds)
Options
RouterDeadInterval (in seconds)
Designated Router
Backup Designated Router
Neighbor Router ID
Grotto
Page - 33
Networking
© Grotto Networking 2004
Rtr Pri
OSPF Hello
packet is
carried in an
IP datagram
OSPF’s Hello Protocol
• Neighbor State Machine
Start
Down
Attempt
Keep saying “hello”
until something
happens...
Hello Received
Hello Received
I’ve received a
hello but don’t
know if they
“know me”.
Init
2-Way
1-Way Received
2-Way Received
Grotto
Page - 34
Networking
© Grotto Networking 2004
I know them and
they know me.
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…
Grotto
Page - 35
Networking
© Grotto Networking 2004
Layers in WDM Networks
Optical Channel
Optical Multiplex
Section
Optical Transport
Section
OCh
OCh
OCh
OMS
OMS
OMS
OTS
OTS
OTS
OTS
OTS
Optical
Multiplexor
Optical Demultiplexor
Optical
Amplifier #1
Optical
Amplifier #2
= Optical Fiber
= Optical Support Channel
for “Transport layer”
= Optical Support Channel
for “multiplex layer”
Grotto
Page - 36
Networking
© Grotto Networking 2004
Optical Add/
Drop
multiplexor
SONET/SDH Layers…
1.5Mbps – 6Mbps
VT Path
Lower order
Virtual Containers
J2 VT trace
STS Path
Higher order
Virtual Containers
J1 Path trace
Tandem Connection
(optional)
Tandem Connection
(optional)
Line
Multiplex Section
No Line trace
Section
Regenerator Section
J0 section trace
Physical
Physical
Multiplexing here
50Mbps – 40Gbps
Multiplexing here
(a) SONET
(b) SDH
STS Path
Tandem Connection
(optional)
PTE
Grotto
Page - 37
Networking
Line
Line
Section
Section
TCTE
Line
LTE
Section
Section
STE
Section
STE
© Grotto Networking 2004
LTE
Line
Line
Section
Section
TCTE
PTE
Layers in TDM Networks
TDM Path
Path
Path
Multiplex Section
MS
MS
Regenerator
Section
RS
RS
RS
TDM
Multiplexor
TDM demultiplexor
Regenerator
(3R) #1
Regenerator
(3R) #2
= Optical Fiber
= Regenerator section overhead
= Multiplex section (line) overhead
= User traffic (path layer)
= Unused time slots
Grotto
Page - 38
Networking
RS
© Grotto Networking 2004
Neighbor Discovery at which layer?
STE-STE neighbor discovery
STE-STE neighbor discovery
PTE
LTE
STE
OMS
OMS
STE
LTE
PTE
LTE-LTE neighbor discovery
Definitions
OMS – Optical Multiplex Section
STE - Section Terminating Equipment
LTE - Line Terminating Equipment
PTE - Path Terminating Equipment
Grotto
Page - 39
© Grotto Networking 2004
Networking
OMS-OMS neighbor discovery
Generalized Automatic Discovery
ITU G.7714 Concepts
• Layer Adjacency Discovery
Data Plane
– Who are my neighbor peers?
• Physical Media Adjacency Discovery Data Plane
– What is the next box I’m physically connected to?
• Control Entity Logical Adjacency
Establishment
Control Plane
– 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 or
subnetwork do? How are you configured?
Grotto
Page - 40
Networking
© Grotto Networking 2004
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”
Grotto
Page - 41
Networking
© Grotto Networking 2004
Trail Trace in SONET/SDH
90 Bytes
Framing
A1
Framing
A2
Trace
J0
BIP-8
B1
Orderwire
E1
User
F1
Data Com
D1
Data Com
D2
Data Com
D3
Pointer
H1
Pointer
H2
Pointer
Action
H3
Sec tion
Overhead
Section (regenerator
section) trace J0
Section DCC
Synchronous Payload
Envelop
Line
Overhead
BIP-8
B2
APS
K1
APS
K2
Data Com
D4
Data Com
D5
Data Com
D6
Data Com
D7
Data Com
D8
Data Com
D9
Data Com
D10
Data Com
D11
Data Com
D12
Sync
S1
REI
M0
Orderwire
E2
Line (multiplex section) DCC
Grotto
Page - 42
Networking
© Grotto Networking 2004
9 rows
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
user
F2
multi
frame
H4
Growth
Z3
Growth
Z4
Contains TCM layer
trace and other items
Tandem
N1
Grotto
Page - 43
Networking
© Grotto Networking 2004
9 rows
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 doesn’t match the received trace.
Grotto
Page - 44
Networking
© Grotto Networking 2004
Current Use of Section Trace Bytes
Grotto
Page - 45
Networking
J0-Based Neighbor Discovery via EMS
Compare
EMS
Report A, Z Values
Report Z, A Values
A: TID, AID
Z: TID, AID
Grotto
Page - 46
Networking
© Grotto Networking 2004
Out-of-band
Control
Issues
• The previous method dumps most of the work
back to the EMS
• Doesn’t 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!)
• Doesn’t 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.
Grotto
Page - 47
Networking
© 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.
Grotto
Page - 48
Networking
© 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.
Grotto
Page - 49
Networking
© 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.
• 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.
Grotto
Page - 50
Networking
© 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!
Grotto
Page - 51
Networking
© 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
Grotto
Page - 52
Networking
© 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 IETF’s Link
Management Protocol (LMP), but is specified
in the UNI1.0/1.1 documents available without
charge at www.oiforum.com
Grotto
Page - 53
Networking
© 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;
Grotto Hello Dead Int.: Waiting time before declaring neighbor dead
Page - 54
Networking
© Grotto Networking 2004
Verifying Port Connectivity
Config (Node ID = 192.28.134.2 , CCID = 1)
1
T
R
R
T
4
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)
3
R
T
T
R
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.5
Node ID =
192.28.134.2
Grotto
Page - 55
Networking
6
© Grotto Networking 2004
Detecting Incorrect Wiring
N1 (192.14.15.2)
1
2
N2 (192.15.2.3)
T
T
R
R
T
T
R
R
10
Config (N1, msg=1, ccid=1)
Config (N1, msg=2, ccid=2)
11
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)
3
T
T
R
R
Grotto
Page - 56
Networking
12
© 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
IPa
IPc
Control
Plane
Grotto
Page - 57
Networking
IP Network
© Grotto Networking 2004
Data
Plane
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 IETF’s 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.
Grotto
Page - 58
Networking
© 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)
Flags
LMP Length
Msg Type
(Reserved)
Type
Message
Type
Message
Type
Message
Type
Message
1
Config
6
BeginVerifyAck
11
TestStatusSuccess
16
LinkSummaryNack
2
ConfigAck
7
BeginVerifyNack
12
TestStatusFailure
17
ChannelStatus
3
ConfigNack
8
EndVerify
13
TestStatusAck
18
ChannelStatusAck
4
Hello
9
EndVerifyAck
14
LinkSummary
19
ChannelStatusRequest
5
BeginVerify
10
Test
15
LinkSummaryAck
20
ChannelStatusRespons
Grotto
Page - 59
Networking
© Grotto Networking 2004
LMP Functions
IP Network
IPa
Control
for A
Grotto
Page - 60
Networking
Conceptual “control channel”
created and maintained via LMP
config and hello messages.
IPb
Control
for B
Conceptual “TE link”, a bundle of
real links agreed upon via LMP
summary messages.
© 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.
Grotto
Page - 61
Networking
© 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
Grotto
Page - 62
Networking
© Grotto Networking 2004
Fundamental Switching Types
•
•
•
•
Circuit Switching
Virtual Circuit Switching
Datagram Switching
Implications for Signaling, Routing, Path
Computation, and Restoration
– MPLS and GMPLS control planes
Grotto
Page - 63
Networking
© Grotto Networking 2004
Differences in Switching Types
• Is connection set up required?
• Is statistical multiplexing possible?
• What are the QoS measures? How is
bandwidth allocated?
• How much work is needed to provide QoS
guarantees?
• How can reliability/protection/restoration be
provided and what are the trade offs?
Grotto
Page - 64
Networking
© Grotto Networking 2004
Forwarding at each switch
• Datagram (e.g., IP)
– Based on complete destination address within the packet.
Any valid destination must be forwarded correctly.
• Virtual Circuits (e.g., MPLS, ATM, Frame Relay)
– Based only on a label with the packet header. Only
packets whose “virtual circuit” has been set up ahead of
time must be forwarded correctly.
• Circuits (not packets)
– Based implicitly on either time slot or wavelength. No
forwarding information needed in data. Only those
circuits whose path has been set up ahead of time must be
forwarded correctly.
Grotto
Page - 65
Networking
© Grotto Networking 2004
Example Network
– Datagram, Virtual Circuits, or Circuits
– Switches 1-5, Hosts A-J
Grotto
Page - 66
Networking
© Grotto Networking 2004
Datagram Forwarding Example
Switch #1
Dest
Port
A
1
B
2
C
3
D
3
E
4
F
4
G
4
H
4
I
3
J
3
I
Grotto
Page - 67
Networking
Switch #2
Dest
Port
A
2
B
2
C
1
D
3
E
2
F
2
G
4
H
4
I
4
J
4
Switch #3
Dest
Port
A
1
B
1
C
1
D
1
E
2
F
4
G
3
H
3
I
3
J
3
Switch #4
Dest
Port
A
1
B
1
C
3
D
3
E
1
F
1
G
2
H
4
I
3
J
3
Switch #5
Dest
Port
A
1
B
1
C
1
D
1
E
2
F
2
G
2
H
2
I
3
J
4
I
I
I
I
© Grotto Networking 2004
I
Graph of our
example network
with switch ports
and hosts shown
Virtual Circuit forwarding Example
• Connections
– Host A to Host J, Host B to Host C, Host E to Host I,
Host D to Host H, and Host A to Host G
Grotto
Page - 68
Networking
© Grotto Networking 2004
Virtual Circuit Forwarding
– Packets are forwarded based on a label in the header
– Labels are not destination addresses, usually much
shorter
– Labels need to be unique on a link but not in a network,
i.e., we can reuse labels on each link.
– Switch forwarding tables consist of a map between
(input port, packet label) to (output port, new packet
label)
– Table entry for each virtual circuit rather than for each
destination (the datagram case)
– Technologies: MPLS, Frame Relay, ATM, X.25
Grotto
Page - 69
Networking
© Grotto Networking 2004
VC Forwarding Table Example
In Port
1
2
1
Switch #1
In Label Out Port
2
3
1
3
1
4
In Port
1
1
3
Switch #4
In Label Out Port
3
2
1
3
1
4
Out Label
5
1
1
In Port
2
2
3
Switch #2
In Label Out Port
5
4
1
1
6
4
Out Label
5
1
1
Out Label
1
1
3
6
3
In Port
1
2
Switch #3
In Label Out Port
1
3
1
3
Out Label
3
1
In Port
1
1
2
Switch #5
In Label Out Port
1
4
3
2
1
3
Out Label
2
1
1
3
1
1
1
Grotto
Page - 70
Networking
© Grotto Networking 2004
“Real” Circuit Forwarding
• No more packets
• Bit streams are distinguished by port and
– Time slots in the TDM case
– Wavelength in the WDM case
– Frequency in the FDM case
• Switching independent of bit stream contents
• TDM example (same connections as VC case)
– Host A to Host J, Host B to Host C, Host E to Host I,
Host D to Host H, and Host A to Host G
Grotto
Page - 71
Networking
© Grotto Networking 2004
“Real” Circuit Tables Example
In Port
1
2
1
Switch #1
In Slot
Out Port
2
3
1
3
1
4
In Port
1
1
3
Switch #4
In Slot
Out Port
3
2
1
3
1
4
Grotto
Page - 72
Networking
Out Slot
5
1
1
In Port
2
2
3
Switch #2
In Slot
Out Port
5
4
1
1
6
4
Out Slot
1
1
3
Out Slot
5
1
1
© Grotto Networking 2004
In Port
1
2
Switch #3
In Slot
Out Port
1
3
1
3
Out Slot
3
1
In Port
1
1
2
Switch #5
In Slot
Out Port
1
4
3
2
1
3
Out Slot
2
1
1
What is MPLS?
• MPLS = “Multi-Protocol Label Switching”
• A virtual circuit form of packet switching
such as frame relay or ATM but with a more
IP centric control plane and built in IP
“adaptation”.
Grotto
Page - 73
Networking
© Grotto Networking 2004
MPLS and IP
• A combine IP router / MPLS switch assigns IP
packets to MPLS flows (virtual circuits)
– This process is known as “classification” and can be
very simple or very complex depending upon the
context.
– This box is known as a Label Edge Router (LER)
• The IP packet header is not touched or looked at
while in the MPLS network
– The LSR (label switched routers) only switch based on
MPLS labels.
Grotto
Page - 74
Networking
© Grotto Networking 2004
An example…
Ingress
router adds
label to packet
Label switching &
packet forwarding
Egress router
removes label
Unlabeled
Packet arrives
Autonomous
system boundary
Grotto
Page - 75
Networking
© Grotto Networking 2004
Label Switched Path (LSP)
Label switched path
A Label Switched Path is like a pipe or tunnel to IP packets.
However its just another term for a virtual circuit. While traveling
on a label switched path, forwarding is based on the label only,
not on destination IP address in packet.
Grotto
Page - 76
Networking
© Grotto Networking 2004
Controlling LSP Set-Up: Explicit
Routing
12.0.0.1
10.1.1.1
Explicit route
10.1.1.7
10.1.1.6
10.1.1.5
10.1.1.2
10.1.1.1
strict
strict
strict
strict
strict
10.1.1.4
POP
10.1.1.2
10.1.1.3
10.1.1.5
10.1.1.6
10.1.1.7
Strict hop
LSP takes direct route to 10.1.1.7
Grotto
be used
for optical
Page - 77 Similar procedure can
© Grotto
Networking
2004 connection set-up.
Networking
“Generalized” MPLS
• Virtual Circuits Real Circuits
– From real labels in MPLS to “virtual labels” in GMPLS
• “Labels” in GMPLS
– TDM where time slots are the implicit labels (e.g.,
SONET)
– FDM where frequencies (or s) are the implicit labels
(e.g., WDM)
– Space-division multiplexing where port numbers are
the implicit labels (e.g., OXCs)
• Generalized labels used in MPLS messaging =
Generalized MPLS
Grotto
Page - 78
Networking
© Grotto Networking 2004
Connection Control and Management
Grotto
Page - 79
Networking
© Grotto Networking 2004
Connection Management & Control
• Connection Management and Connection
Control via Signaling
• Signaling for Optical Networks
• Introduction to RSVP-TE with GMPLS
extensions
Grotto
Page - 80
Networking
© Grotto Networking 2004
Connection Control
• Concerned with:
– Creating or removing cross connects in network
element such as switches and/or multiplexers
for the establishment (setup) or removal
(teardown) of a connection.
• Three methods available
– Via a management system
– Via signaling
– Via a combination of the management and
signaling
Grotto
Page - 81
Networking
© Grotto Networking 2004
EMS based Provisioning
Grotto
Page - 82
Networking
© Grotto Networking 2004
EMS/NMS Interaction
NMS
set-up request
CSNC: Create Sub-network Connection
CXCon: Create cross Connect
CSNC
EMS
CSNC
CSNC
O3
O9
EMS 1
O2
EMS 2
O4
O10
O1
CXCon
CXCon
O8
O6
Source
CXCon
M5
O7
M4
M2
Core Network
M1
M6
M3
Metro SubNetwork 1
Grotto
Page - 83
Networking
Metro SubNetwork 2Destination
© Grotto Networking 2004
Signaling base Provisioning
Soft Permanent
Connection (SPC)
model
Grotto
Page - 84
Networking
© Grotto Networking 2004
Connection Provisioning
Inventory & Resource Management
2. Global Topology Dissemination
1. Neighbor Discovery
NETWORK
MGMT PLANE
User
User
OUNI
CONTROL PLANE
DATA PLANE
3. Connection Request
4. Path Calculation (NE-based or EMS-based)
Dynamic Provisioning 5. Establish Connection via signaling
Grotto
Page - 85
Networking
© Grotto Networking 2004
Connection Provisioning
• Goals
– Offload the EMS by distributing control
– Also adds scalability, survivability and potential
for more services
Grotto
Page - 86
Networking
© Grotto Networking 2004
Connection Provisioning (contd.)
• General Solution: Use a signaling protocol!
– This is a radically new idea, i.e., signaling has only
been used in the telephone network for 60 years or so…
– Need to be careful with “behavioral” aspects…
• e.g., call clearing is not an acceptable default behavior in the
transport domain!
– Other benefit: a robust, bandwidth efficient restoration
mechanism…
– There are a number of different signaling protocols that
could be extended
• Currently both RSVP and CR-LDP are part of MPLS
• ITU is including PNNI as part of G.ASTN/G.ASON
Grotto
Page - 87
Networking
© Grotto Networking 2004
Interoperability
• Related Problem
– Lack of interoperability between vendors for
connection provisioning
– Partially based on lack of interoperability between
different management systems
• Use a signaling interface
– More limited scope – connection control, not overall
management
– Local to the interface between network elements
Grotto
Page - 88
Networking
© Grotto Networking 2004
Optical Connection Signaling
O1
– Establish path from source to
destination
– Commit bandwidth and channel
(timeslot, wavelength, fiber)
– Release when no longer in use
– Restore in case of failure
O2
Request (label)
Response (P1)
Request (label)
Response (P4)
O5
O3
Grotto
Page - 89
Networking
© Grotto Networking 2004
O4
GMPLS Signaling
Grotto
Page - 90
Networking
© Grotto Networking 2004
“Generalized” MPLS
– TDM where time slots are labels (e.g., SONET)
– FDM where frequencies (or s) are labels (e.g., WDM)
– Space-division multiplexing where ports are labels
(e.g., OXCs)
– Generalized labels used in MPLS messaging =
Generalized MPLS
– Two options are RSVP and CR-LDP
• RSVP is by far the more implemented option
Grotto
Page - 91
Networking
© Grotto Networking 2004
RSVP: Resource Reservation
Protocol
• RSVP reserved router resources for multicast or unicast “sessions”
– Think Internet broadcast sessions
• RSVP reservations were uni-directional, from source to destination
• RSVP was/is not a routing protocol
– Resources are reserved along the path to the IP destination as
determined by the underlying routing protocol
• RSVP was Soft State
– Reservation is dropped unless periodically refreshed
• RSVP was never widely deployed
Grotto
Page - 92
Networking
© Grotto Networking 2004
Main RSVP Constructs
• Path Message
– Sent from source to destination to inform
destination about traffic characteristics.
– Routed like any IP packet
• Resv Message
– Sent from destination to source along the
reverse path.
– Establishes reservation for the flow from source
to destination
Grotto
Page - 93
Networking
© Grotto Networking 2004
Path and Resv Message Flow
Source
Path message flow, addressed directly
to the unicast/multicast destination
Resv message flow, hop-by-hop
A
B
G
C
D
F
H
E
I
Receiver 1
Grotto
Page - 94
Networking
Receiver 2
© Grotto Networking 2004
TE Extensions to RSVP (RSVP-TE)
• Label Object
– Creates label-based forwarding table
– Bypasses IP routing
• Explicit Route Object
– A way to fix the path (for Traffic Engineering)
– Can be “loose” or “strict” routing
• Reference:
RFC 3209
Extensions to RSVP for LSP Tunnels
Grotto
Page - 95
Networking
© Grotto Networking 2004
Explicit Route Example
12.0.0.1
Forwarding based
On Labels
10.1.1.1
10.1.1.2
10.1.1.3
10.1.1.5
10.1.1.6
IP Shortest Path
PATH Message
{ER=10.1.1.7,
10.1.1.6, 10.1.1.5,
10.1.1.2, 10.1.1.1}
Grotto
Page - 96
Networking
10.1.1.4
10.1.1.7
POP
IP address mapped to LSP
Label inserted
© Grotto Networking 2004
GMPLS Extensions
– Generalized Label Object
• Time Slot, Wavelength, Fiber
• Virtualized label, since it is mapped to a real circuit
– Upstream Label
• For bi-directional connection establishment
– TE-Link
• Separation between the control and data links
– Reliability Issues
• Compensate for RSVP Soft State and refresh requirements
• Compensate for unreliable IP transport
Grotto
Page - 97
Networking
© Grotto Networking 2004
Connection Establishment: Basic Idea
Path message with Generalized Label Request object
Resv message with Generalized Label object
Path and Resv sent over control channel
Path and Resv may be entirely internal to the optical network (soft PVC model)
or may be initiated by external clients
Path (Gen. Label Request)
1
Resv (Generalized Label)
Resv (Generalized Label)
A
B
Grotto
Page - 98
Networking
C
5
2
3
Path (Gen. Label Request)
6
3
© Grotto Networking 2004
2
4
5
6
Generalized Label Request Object
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Length
| Class-Num (19)|C-Type (4)[TBA]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type |
G-PID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type:
1
Packet
5
SDH
6
SONET
8
Lambda (photonic)
9
Fiber
Grotto
Page - 99
Networking
GPID, SONET Related:
22 DS1 SF Asynchronous
23 DS1 ESF Asynchronous
24 DS3 M23 Asynchronous
25 DS3 C-Bit Parity
26
27 STS
28 POS - No Scrambling, 16 bit CRC
29 POS - No Scrambling, 32 bit CRC
30 POS - Scrambling, 16 bit CRC
31 POS - Scrambling, 32 bit CRC
32 ATM mapping
© Grotto Networking 2004
SONET/SDH Label Format
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
S
|
U
|
K
|
L
|
M
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each letter indicates a possible branch number starting at the parent node in
the multiplex structure. Branches are considered as numbered in increasing
order, starting from the top of the multiplexing structure. The numbering
starts at 1, zero is used to indicate a non-significant field. (U and K are set to
0 for SONET)
Grotto
Page - 100
Networking
© Grotto Networking 2004
SONET Label Example
STS-N
xN
SPE
x7
VT group
VT-6
SPE
6312 kbit/s DS2/T2
x2
VT-3
SPE
3152 kbit/s DS1C
x3
VT-2
SPE
2048 kbit/s E1
VT-1.5
SPE
1544 kbit/s DS1/T1
SONET
S
44736kbit/s DS3/T3
x1
L
x4
M
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
0x7d
| 0x0
| 0x0
| 0x2
| 0x1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This label indicates the 125th STS-1 (in a STS-192 link), the 2nd VT group and the
first VT SPE within the group.
Grotto
Page - 101
Networking
© Grotto Networking 2004
Path Setup - Example
10.3.4.2
1
9
TE Link
2
10.4.4.2
3
2
8
6
5
7
10.1.1.1
5
OXC 1
3
10.2.1.2 OXC 2
10.2.5.2
OXC 3
An STS-48c connection to be established from OXC1, port 9 to OXC 3, port 7
Path:
Session(10.4.4.2, 0, 10.3.4.2)
PHOP(10.3.4.2), LIH(9), IF ID(9)
Gen. Label_Request(SONET, POS)
Sender_Tspec(STS-48, Std. Concat, NCC=1, NVC=0,
Multiplier = 1, Transp.=Path )
Protection(No protection)
ERO (10.1.1.1, 1, 10.2.1.2, 3, 10.2.5.2, 6, 10.4.4.2)
Sender_Template(10.3.4.2, 00)
Upstream label (1) /* All links assumed to be OC-48 */
Grotto
Page - 102
Networking
© Grotto Networking 2004
Path Setup - Example
10.4.4.2
10.3.4.2
1
9
TE Link
2
3
2
8
6
5
7
10.1.1.1
5
OXC 1
3
10.2.1.2 OXC 2
10.2.5.2
OXC 3
An STS-48c connection to be established from OXC1, port 9 to OXC 3, port 7
Path:
Session(10.4.4.2, 0, 10.3.4.2)
PHOP(10.1.1.1), LIH(1), IF ID(5)
Gen. Label_Request(SONET, POS)
Sender_Tspec(STS-48, Std. Concat, NCC=1, NVC=0,
Multiplier = 1, Transp.=Path )
Protection(No protection)
ERO (10.2.1.2, 3, 10.2.5.2, 6, 10.4.4.2)
Sender_Template(10.3.4.2, 00)
Upstream label (1) /* All links assumed to be OC-48 */
Grotto
Page - 103
Networking
© Grotto Networking 2004
Path Setup - Example
10.3.4.2
1
9
TE Link
2
3
2
10.4.4.2
8
6
5
7
10.1.1.1
5
OXC 1
3
10.2.1.2 OXC 2
10.2.5.2
OXC 3
An STS-48c connection to be established from OXC1, port 9 to OXC 3, port 7
Path:
Session(10.4.4.2, 0, 10.3.4.2)
PHOP(10.2.1.2), LIH(3), IF ID(5)
Gen. Label_Request(SONET, POS)
Sender_Tspec(STS-48, Std. Concat, NCC=1, NVC=0,
Multiplier = 1, Transp.=Path )
Protection(No protection)
ERO (10.2.5.2, 6, 10.4.4.2)
Session_Attribute (S(1), H(1), 0x04)
Sender_Template(10.3.4.2, 00)
Upstream label (1) /* All links assumed to be OC-48 */
Grotto
Page - 104
Networking
© Grotto Networking 2004
Path Setup - Example
10.3.4.2
1
9
TE Link
2
3
2
10.4.4.2
8
6
5
7
10.1.1.1
5
OXC 1
3
10.2.1.2 OXC 2
10.2.5.2
OXC 3
An STS-48c connection to be established from OXC1, port 9 to OXC 3, port 7
Path:
Session(10.4.4.2, 0, 10.3.4.2)
PHOP(10.2.5.2), LIH(6), IF ID(7)
Gen. Label_Request(SONET, POS)
Sender_Tspec(STS-48, Std. Concat, NCC=1, NVC=0,
Multiplier = 1, Transp.=Path )
Protection(No protection)
ERO (10.4.4.2)
Sender_Template(10.3.4.2, 00)
Upstream label (1)
Grotto
Page - 105
Networking
© Grotto Networking 2004
Path Setup - Example
10.3.4.2
1
9
TE Link
2
3
2
10.4.4.2
8
6
5
7
10.1.1.1
5
OXC 1
3
10.2.1.2 OXC 2
10.2.5.2
OXC 3
An STS-48c connection to be established from OXC1, port 9 to OXC 3, port 7
Resv:
Session(10.4.4.2, 0, 10.3.4.2)
NHOP(10.4.4.2), LIH(6), IF ID(7)
Gen. Label (1)
Flowspec(STS-48, Std. Concat, NCC=1, NVC=0, Multiplier =
1, Transp.=Path )
Sender_Template(10.3.4.2, 00)
Grotto
Page - 106
Networking
© Grotto Networking 2004
Signaling Reliability
• Messages sent over unreliable IP network
– Each message carries a unique Message ID
– Ack required to verify receipt
– Also to reduce refresh overhead – just send ID
• Soft State/Hard State
– When the control plane at a node fails, the data plane
connections must be maintained (not Soft State)
– New Restart Capability object is used in Hello
messages to indicate the presence of restart procedures
in a node
Grotto
Page - 107
Networking
© Grotto Networking 2004
Graceful Connection Deletion
• Regular RSVP-TE connection deletion:
OXC1
Tear Path and
Resv state
OXC3
OXC2
Path tear
Tear Path and
Resv state
Path tear
Tear Path and
Resv state
In optical networks, OXC2 would immediately see a failure when
OXC1 removes its path and resv state (i.e., fabric cross-connections),
and may begin to resort to connection protection procedures and raise
management alarms.
Grotto
Page - 108
Networking
© Grotto Networking 2004
Graceful Deletion Solution
GMPLS RSVP-TE introduces an extra phase before actual
removal of connection state, to indicate deletion in progress.
OXC1
Mark deletion
in progress.
Set timer.
Mark deletion
Mark deletion
in progress.
in progress.
Path with
Path with
admin status Set timer.
admin status Set timer.
Resv with
admin status
Tear Path and
Resv state
Grotto
Page - 109
Networking
OXC3
OXC2
Path tear
Resv with
admin status
Tear Path and
Resv state
Path tear
© Grotto Networking 2004
Tear Path and
Resv state
Restart Capability Object
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Length
| Class-Num(TBD)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Restart Time
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Recovery Time
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Restart time: Time in milliseconds the neighbor should wait for restoral of
signaling once signaling connectivity has been lost.
Recovery time: Time in milliseconds that the sender is willing to retain data plane
state while the restart procedure is in progress (following restoral of signaling
connectivity). Can be set to infinity.
Grotto
Page - 110
Networking
© Grotto Networking 2004
Case 1: Recovery from Signaling
Channel Failure
Restart Node
Helper Node
Hello
(Same Source Instance)
Hello
(Same Source Instance)
Stop self-refresh
Stop self-refresh
Srefresh
Ack
Srefresh
RSVP connection
refresh timeout,
delete connection
Grotto
Page - 111
Networking
Ack
© Grotto Networking 2004
RSVP connection
refresh timeout,
delete connection
Case 2: Recovery from
Control Processor Failure
Restart Node
Helper Node
Hello
(New Source Instance)
Hello
Start recovery timer
Stop self-refresh
Path (Recover_Label 1)
Ack
Recovery timer
expired,
remove connections for
which there are no
Path Messages
Grotto
Page - 112
Networking
Path (Recover_Label 2)
Ack
© Grotto Networking 2004
RSVP connection
refresh timeout,
delete connection
Future Work
• Features
–
–
–
–
Restoration/Protection
Crankback
Soft Permanent Connections
…
• Testing and Corrections
Grotto
Page - 113
Networking
© Grotto Networking 2004
ASON Signaling
Grotto
Page - 114
Networking
© Grotto Networking 2004
ITU-T G.ASON Signaling Protocols
G.8070
ASTN
G.8080
ASON
G.7712
DCN
G.7713.1
PNNI
G.7713
Signaling
G.7713.2
RSVP
G.7714
Discovery
G.7715
Routing
G.7713.3
CR-LDP
4 week
Last Call
Contribution
Grotto
Page - 115
Networking
G.7716
Link Resource Mgmt
Draft
Recommendation
SG/WP
Consent
© Grotto Networking 2004
Comment
Review
ITU Rec
SG/WP
Decided
t
ITU-T G.7713 Distributed Connection
Mgmt. Reference Model
Domain 1
ARA UNI
AUSN
Domain n
I-NNI
ASC1
SN1
ISC1
SN
ZSC1
ZSCn
UNI
ZRA
ZUSN
SN
ARA – A-end requester agent
ZRA – Z-end requester agent
AUSN – A-end user sub-network
ZUSN – Z-end user sub-network
Grotto
Page - 116
Networking
E-NNI ASCn I-NNI
ASC: A-end Sub-Network Controller
ZSC: Z-end Sub-Network Controller
ISC: Intermediate Sub-Network Controller
SN: Sub-Network
© Grotto Networking 2004
Topology/Routing
Grotto
Page - 117
Networking
© Grotto Networking 2004
Topology and Resource
Discovery/Dissemination
• Motivations
• Functionality & Information
• Optical use of link state routing
protocols
• GMPLS routing
• Beyond OSPF areas…
Grotto
Page - 118
Networking
© Grotto Networking 2004
Why do Topology and Resource
Discovery/Dissemination?
• Basic Network Inventory
– Required for operations and planning
• Topology and Resource Utilization
– Required for connection path
selection/computation
• Disaster Recovery
– Want timely information of what’s available in
the network (nodes, link, spare capacity, etc…)
Grotto
Page - 119
Networking
© Grotto Networking 2004
Approaches
• Centralized (e.g., EMS-based)
– EMS communicates with individual nodes to obtain
neighbor information
– Nodes may run neighbor discovery prior to this
– EMS maintains complete topology & resource
information
• Distributed
– Nodes run a distributed protocol (e.g., an link state
routing protocol adapted for this purpose)
– All nodes maintain complete topology information.
Resource information may be abstracted
Grotto
Page - 120
Networking
© Grotto Networking 2004
EMS-based Topology Discovery
• Use neighbor info to perform depth/breadth first
search for other nodes
– Neighbor information would include address for EMS
to communicate with nodes.
Node B
Node D
Node G
Node H
Node A
Node J
Node E
Node C
Grotto
Page - 121
Networking
© Grotto Networking 2004
Node F
Optical Link State Routing
• A way to discover and disseminate topology
and resource information independent of the
EMS
• Offloads the EMS from performing this task
• Makes this information available at every
node
enhanced robustness in the event of major
network problems
• Timely updates of changes to all nodes
Grotto
Page - 122
Networking
© Grotto Networking 2004
Partial distribution: an example
• Link state routing for topology discovery
– Gives “plug and play” for NE’s.
• EMS for connection provisioning
– Doesn’t require call processing on the network elements and hence
keeps them simpler
EMS obtains topology
from any node in the
network
Node D
Node B
Topology
information
EMS #2
EMS #1
Node A
Node E
EMS provisions
connection via Xconnects
on each node in the path
Grotto
Page - 123
Networking
Node C
© Grotto Networking 2004
Xconnect provisioning
from EMS
Interoperability & Optical Routing
• EMS based topology/resource discovery
status monitoring is proprietary
• Link State Routing can be interoperable
however typical problems exist: multiple
protocols and multiple extensions
• Without interoperability of connection
control there is little use for this
information. General restoration options not
possible…
Grotto
Page - 124
Networking
© Grotto Networking 2004
Information Needed for Path Computation
& Operations
• Inventory & Connectivity
– Nodes, Links & End systems
– End systems typically summarized by addresses
• Resource Utilization
– How much capacity is available on a link
– Dynamically changing information
• Switching Capability of Nodes
– Packet switching, TDM, WDM
Grotto
Page - 125
Networking
© Grotto Networking 2004
Information Needed for Path Computation
& Operations
• Underlying Protection
– Linear (1+1, 1:1, 1:N), Ring, etc...
• Diverse Routing Information -– Shared Risk Link Groups (SRLGs)
Grotto
Page - 126
Networking
© Grotto Networking 2004
Multi-Layer Example: Specifying Shared
Risk Link Groups (SRLGs)
– Interoperability between DWDM equipment and
SONET/SDH layer equipment
• The Shared Risk Link Group (SRLG) is a summarization
or abstraction of lower transport layer properties
• We illustrate its use applied to a WDM layer example
composed of WDM add/drop multiplexer (single
wavelength or bands of wave lengths)
• It is coded as a list of 32-bit integers that gets advertised
as a property of a link within a link state routing protocol
such as OSPF or IS-IS
Grotto
Page - 127
Networking
© Grotto Networking 2004
SRLG Network Example (fictitious)
Suppose we know the WDM layer looks as follows. Then we can assign 32-bit “span”
numbers and formulate SRLGs for SONET lines A and B as indicated below.
A
1701
2112
A
B
1313
B
SONET line A SRLG (2112, 1701)
Multi-layer discovery takes place at these points.
Raw topology information is transferred from DWDM
system via service discovery protocol and then
turned into SRLG information for distribution within
routing protocol.
Grotto
Page - 128
Networking
SONET line B SRLG (2112, 1313)
© Grotto Networking 2004
Routing roles:
Traditional IP link state IGPs (OSPF, IS-IS)
• Discovery portion
– Hello protocol (assumes data and control planes the same)
– Not applicable, in general, to optical networks
• Topology dissemination
– Information concerning nodes (including reachability) and links in
the network
– Want and need more information for optical networks
• Route computation
– To give IP forwarding table (heavily constrained due to hop by hop
forwarding paradigm)
– Overly simplistic for optical networks
Acronyms: IP (Internet Protocol), IGPs (Internal Gateway Protocols), OSPF (Open Shortest
Path First), IS-IS (Intermediate System to Intermediate System)
Grotto
Page - 129
Networking
© Grotto Networking 2004
Link State Routing Example: OSPF
– OSPF: Open Shortest-Path First
• Similar in concept but different in protocol messages from IS-IS
– Link State Advertisements (LSAs) are generated by each
node describing its local piece of the routing topology
(adjacent links and neighbors)
– Reliable flooding of LSAs to all nodes in the network
(periodic retransmit until acknowledgement received +
routine refresh every 30 min)
Grotto
Page - 130
Networking
© Grotto Networking 2004
Link State Information
• Concept
– Every node (router) in the network knows about the links that
connect it to other nodes in the network via the discovery process.
All this information combined would give us sufficient information
to construct a graph of the network.
– The link state protocols will distribute the complete set of this
information to every router.
– This collection of link state information is often referred to as a
link state database (not at all related to SQL and such databases).
Sometimes, we’ll just refer to this as network topology
information.
Grotto
Page - 131
Networking
© Grotto Networking 2004
Sounds Simple Enough…
• Use a hello sub-protocol to
– Discovery neighbors and monitor the links
• Assemble Discovered information into
packets
– We called these link state advertisements or
LSAs
Grotto
Page - 132
Networking
© Grotto Networking 2004
Sounds Simple Enough…
• Distribute the LSAs to all the other routers
– Need this to be reliable, since every router needs
exactly the same link state database for route
computations
– Need this to be efficient, since we can’t use up all the
link bandwidth on the links for routing and we may
have some low bandwidth links.
– Need this to respond to changes in a timely manner.
– Hmm, maybe this part isn’t so simple after all…
Grotto
Page - 133
Networking
© Grotto Networking 2004
Constructing the Topology Database
• Hello packets discover neighbors
• Two-way stage—communication established
• Exstart stage—master and sequence established
R1
Hello, None seen
Hello, R2 seen
DD Seq. No. x, M
DD Seq. No. y, M
DD Seq. No. y, S
Grotto
Page - 134
Networking
© Grotto Networking 2004
R2
Example Topology Info from
Discovery
– Now we just need to share this info…
Grotto
Page - 135
Networking
© Grotto Networking 2004
Practicalities in distributing
Information
• Ownership of Link State Information
– A router “owns” a link as far as its advertisement to the
rest of the world is concerned. For bi-directional links
each half is “owned” by a different router.
– Each item of link state info (e.g. each link) is uniquely
identified. In addition this information will also have a
sequence number so receiving routers can update there
databases with the latest information
Grotto
Page - 136
Networking
© Grotto Networking 2004
Practicalities in distributing
Information
• Ageing of Information
– All topology information times out.
– The originating router is responsible for
keeping its link state information up to date.
Grotto
Page - 137
Networking
© Grotto Networking 2004
OSPFv2 Link State Advertisements
• Header
– LS age: the time in seconds from origination
– LS type: Router, Network, Summary (2 types), external
(we’ll only look at Router)
– Advertising Router: the router that originates the LSA
– Link State ID: For router LSAs same as Advertising Router
Grotto
Page - 138
Networking
© Grotto Networking 2004
OSPFv2 Router LSA
– Contains a list of all the links connected to the router
Grotto
Page - 139
Networking
© Grotto Networking 2004
Different Types of LSAs
•
•
•
•
•
•
•
Router (LSA type 1)
Network (LSA type 2)
Summary (LSA type 3)
ASBR (LSA type 4)
External (LSA type 5)
NSSA external (LSA type 7) (RFC 1587)
Opaque LSA (Type 10) (RFC 2370)
Grotto
Page - 140
Networking
© Grotto Networking 2004
Router LSA
• Describes the state and cost of the router’s links to
the area
• All of the router’s links in an area must be
described in a single LSA
• Flooded throughout the particular area and no
more
Grotto
Page - 141
Networking
© Grotto Networking 2004
OSPFv2 Router LSA
• Key Fields
– Metric: the link cost
– Type:
•
•
•
•
1
2
3
4
Point-to-point connection to another router
Connection to a transit network
Connection to a stub network
Virtual link (beyond our scope here…)
– Link ID: Depending on the link type
•
•
•
•
Grotto
Page - 142
Networking
1
2
3
4
Neighboring router's Router ID
IP address of Designated Router
IP network/subnet number
Neighboring router's Router ID
© Grotto Networking 2004
LSA Distribution Procedures
• LSA Database Synchronization
– Situations: routers coming up or establishing a new neighbor
adjacency
– Let your neighbor know a summary of the LSAs in your data base.
Method OSPF database description packet contains just the
LSA headers.
– When you receive such a packet you inspect the headers to see if
you have all the LSAs and the most recent version of them. If not
request only those that you need. Method OSPF link state
request packet.
– Upon receiving a link state request packet the neighbor will send
the complete LSA(s) in an OSPF link state update packet.
Note the bandwidth efficiency of this procedure
Grotto
Page - 143
Networking
© Grotto Networking 2004
Database Description Packets
• Contain link state database headers
• Describe the current LSDB database
• Exchange stage
R1
R2
DD Seq. No. x+1, M
DD Seq. No. x+1, S
DD Seq. No. x+n, M
DD Seq. No. x+n, S
Grotto
Page - 144
Networking
© Grotto Networking 2004
Link State Request and Update Packets
• Request for specific parts of database
• Send only database updates requested
R1
Link State Request
Link State Update
Link State Request
Link State Update
Grotto
Page - 145
Networking
© Grotto Networking 2004
R2
LSA Distribution Procedures
• Updating LSA
– Situations: LSA will time out, link have either come up
or have gone down.
– Method “Reliable flooding” of the pertinent LSAs
– Reliable in that positive acknowledgements are used in
transferring LSAs between neighbors, i.e., it will keep
sending until it receives an acknowledgement.
– Flooding in the sense that a router will forward on
(reliably) the LSA to all its neighbors except the one it
received the packet from.
Hence we see that this routing protocol has to institute its own
reliability procedures, similar to what we saw at the data link layer.
Grotto
Page - 146
Networking
© Grotto Networking 2004
Flooding Process
LS Update
LS Ack
R2
LS Ack
LS Update
R1
LS Update
R3
Grotto
Page - 147
Networking
LS Ack
© Grotto Networking 2004
Okay, I’ve got the Topology, now
what?
• Calculate the paths to the destinations
– We’ve got an up to date graph representing the network
we now run a routing algorithm on this graph.
• Datagram Networks
– All routers must run the same path selection algorithm
to find the next hop to each destination.
– In the case of OSPF Dijkstra’s algorithm is used.
• Virtual Circuit or “real” Circuit Networks
– In general only one router will perform the path
calculation for a VC and then notify others of the route
via signaling. No constraints are put on the path
selection algorithms run on the switches.
Grotto
Page - 148
Networking
© Grotto Networking 2004
When the State of a Link Changes
R1
R2
LSA
Ack
Link State Table
Every router in
area hears a
specific link LSA.
Each router
computes
shortest path
routing table
Grotto
Page - 149
Networking
SPF Algorithm
Old Forwarding Table
© Grotto Networking 2004
New Forwarding Table
Traditional OSPF ...
– A flooded LSA will not be accepted if the current database
copy was received less than 1 (MinLSArrival) second back
(to guard against routers that are updating their LSAs too
frequently).
– Link-state database (distributed and replicated at each node;
contains all LSAs)
– Link-state database used to compute IP routing table
– Router LSA: originated by a router and contains the router’s
active intrefaces, IP addresses, and neighbors.
– Each link has an additive cost metric used for shortest path
computation.
Grotto
Page - 150
Networking
© Grotto Networking 2004
Traditional OSPF ….
– OSPF Hello protocol (for neighbor discovery): Hello
packets are sent out every 10 (HelloInterval) seconds; a link
is considered for forwarding data packets if it is up in both
directions.
– Each router computes a shortest path tree rooted at itself
using Dijkstra’s Shortest Path First (SPF) algorithm
– Load balancing of traffic using equal-cost multipaths.
Grotto
Page - 151
Networking
© Grotto Networking 2004
Hello Instances
Hello
10.1.1.1
10.1.1.2
R2
R1
Hello
10.1.2.1
Hello
10.1.2.2
Hello is run over each adjacency, numbered or unnumbered.
Database synchronization is run over only one link with each
neighbor.
R3
Grotto
Page - 152
Networking
© Grotto Networking 2004
OSPF extensions for GMPLS
– An optical switch typically has a high number (~ 256)
of interfaces (ports) leading to high number of OSPF
adjacencies between neighboring nodes. This increases
the number and size of LSAs exchanged. Solution: Link
Bundling.
– Routing in optical networks needs resource information
like link type, bandwidth (number of channels), etc.
Solution: Optical (opaque) LSAs to disseminate
resource information.
Grotto
Page - 153
Networking
© Grotto Networking 2004
OSPF extensions for GMPLS
– Diverse routing of working and protection paths
in optical networks requires knowledge of the
SRGs that each link belongs to. Solution:
Optical (opaque) LSAs to disseminate SRG
information.
Grotto
Page - 154
Networking
© Grotto Networking 2004
Link Bundling Example
Component Link
TE Link 1
SRLG-1
SRLG-2
SRLG-3
TE Link 2
Grotto
Page - 155
Networking
© Grotto Networking 2004
GMPLS routing at the IETF
• draft-ietf-ccamp-gmpls-routing-09.txt
– Introduces the basic concepts of link protection type,
SRLG, and link multiplex capability.
– RFC to be
• draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
– Specific codings for OSPF.
– In general the TE extensions for routing are inadequate
for SONET/SDH bandwidth management purposes.
– RFC to be
Grotto
Page - 156
Networking
© Grotto Networking 2004
Path Computation
In networks where multiple switches must be traversed
to transfer information from source to destination a path
must be chosen and the individual switches along the
path must take appropriate action to forward the
information.
Grotto
Page - 157
Networking
© Grotto Networking 2004
Path Computation
• Path Computation is concerned with
– Finding the path from source to destination
– The information forwarding that occurs at
each switch
• Computation applies to
– Datagram network layers like IP
– Virtual Circuit network layers like MPLS,
ATM, etc…
– Circuit switch network layers like SONET,
the T1, and the E1 TDM hierarchies.
Grotto
Page - 158
Networking
© Grotto Networking 2004
Path Selection/Computation
•
•
•
•
•
Path computation paradigms
Shortest path algorithms
Differences between optical and IP routing
Diverse path algorithms
Network optimization approaches
Grotto
Page - 159
Networking
© Grotto Networking 2004
Path Computation Paradigms:
Centralized
– Can take into account global information on
network resources and existing connection
paths to implement optimal computation
procedures
– Can be used to optimally design networks
based on forecasted demands for predeployment capacity planning
– Offline algorithms can have knowledge of
the entire set of demands and make more
efficient use of network capacity
Grotto
Page - 160
Networking
© Grotto Networking 2004
Path Computation Paradigms:
Distributed
– A single centralized path computation server can be
a performance bottle neck.
– Many restoration techniques can utilize distributed
path computation
– Ability to perform distributed path computation
increases network resilience.
– Note: not necessarily a distributed computation, but
a computation that doesn’t need to be run at a
single centralized location
Grotto
Page - 161
Networking
© Grotto Networking 2004
Path Computation Algorithms
• Shortest Path Techniques
2
NE
2
4
1
NE
1
NE
4
2
2
NE
7
NE
5
1
2
2
2
2
6
Grotto
Page - 162
Networking
2
2
NE
3
2
Iteration
Links are
characterized by
a single link
weight
Label (d1, …,
d7)
(0, 3, 2, 5, 4, 6, 7)
Candidate V
{7}, remove 7.
NE
6
Previous Node (n1,
…,n7)
(x, 3, 1, 2, 2, 5, 4)
Very good algorithms are available for solving this class
of problems, e.g., Dijkstra and Bellman-Ford
© Grotto Networking 2004
Output from
Dijkstra’s algorithm
originating at node 1
Shortest Path Algorithms
• Setting the Link Weights
– link wt. = link miles => route miles shortest
path
– link wt. = 1 => minimum hop count path
– link wt. = ln(pi) , where pi is the probability of
failure on a link i, => lowest probability of
failure path
– Link wt. = switch transit delay + fiber
propagation delay => minimum delay path
Grotto
Page - 163
Networking
© Grotto Networking 2004
Differences Between Optical Network
Routing and IP Routing
• IP routing
– Per hop forwarding of datagrams based on destination
IP address
– Every router must have exactly the same network
topology information (links, nodes, and link wts.)
– Every router must run exactly the same path
computation algorithm
– Failure to insure these last two requirements can result
in routing loops and “black holes”
Grotto
Page - 164
Networking
© Grotto Networking 2004
Differences Between Optical Network
Routing and IP Routing...
• Optical routing
– Circuits are source routed; no loops possible
– No standardization of path computation required
– Okay for information to be slightly out of date, e.g.,
available capacity information; worst case “crank-back”
of connection
– Unless restoration action is taken based on link state
updates, routing is not service impacting in transport
domain
Grotto
Page - 165
Networking
© Grotto Networking 2004
Implications for Shortest Path
Algorithms
• IP case:
– One set of link weights is assigned and used for all path
computations. Changes to weights require recalculation
of paths at all routers.
• Optical (circuit switched) case:
– Different connections can use different criteria
different sets of links weights can be used per
connection.
– Changes in link weights do not require recalculation of
existing paths
– Path Computation does not require standardization in
circuit switched networks
Grotto
Page - 166
Networking
© Grotto Networking 2004
Simple Constraints
• Remove links that don’t satisfy specific criteria
before computing shortest path
– Example 1: Find the shortest path from node 1 to node
7 restricted to only protected SDH links.
NE
2
NE
4
2
2
4
Unprotected
links
1
NE
1
NE
7
NE
5
1
2
2
Shortest path
with no
constraints
Grotto
Page - 167
Networking
2
2
NE
3
2
© Grotto Networking 2004
NE
6
Simple Constraints
• Pruned network
– Example 1 Solution: Find the shortest path from node 1
to node 7 on pruned network using Dijstra’s algorithm.
NE
2
NE
4
2
2
4
1
NE
1
Shortest path
with
protection
constraint
Grotto
Page - 168
Networking
NE
7
NE
5
2
2
Unprotected
links pruned
2
NE
3
© Grotto Networking 2004
NE
6
Simple Constraints
• Example 2 Bandwidth constraints
– Given the following OC-192 network with a single
STS-1 signal routed. Find the shortest path for an STS192c
NE
2
NE
4
2
2
4
1
NE
1
NE
7
NE
5
1
2
2
STS-1
Connection
over OC-192
links
Grotto
Page - 169
Networking
2
2
NE
3
2
© Grotto Networking 2004
NE
6
Simple Constraints
• Example 2 Bandwidth constraints
– Solution: Prune all path with insufficient bandwidth to
support an STS-192c then run a shortest path algorithm.
NE
2
STS-192c path
NE
4
2
2
4
1
NE
1
NE
7
NE
5
1
2
2
Links with
insufficient
bandwidth to support
an STS-192c pruned
Grotto
Page - 170
Networking
NE
3
© Grotto Networking 2004
NE
6
Diverse Route Computation
• Problem:
– Find two disjoint paths between the same source and
destination
– Want the total minimum cost (based on both)
– Want the paths link diverse
– May want the paths node diverse (stronger)
• Applications:
– 1+1 Protected Lightpaths (SNCP style protection)
– Network client layer network resiliency
Grotto
Page - 171
Networking
© Grotto Networking 2004
Diverse paths via pruning
Find the first shortest path, then prune those links
NE
2
NE
8
2
Path cost = 3
8
2
2
NE
1
NE
4
1
NE
3
1
2
4
2
NE
5
NE
7
Grotto
Page - 172
Networking
NE
6
1
8
© Grotto Networking 2004
Diverse paths via pruning
Find the second shortest path in the modified graph
Path cost = 12
NE
2
NE
8
2
8
Total for both
paths= 15
2
2
NE
1
NE
4
NE
3
NE
6
2
4
2
NE
5
NE
7
Grotto
Page - 173
Networking
8
© Grotto Networking 2004
Diverse paths via pruning
• Questions
– Are these the lowest cost set of diverse paths?
• Why should they be? We computed each
separately…
– Are there situation where this approach will
completely fail?
• Let’s look at another network…
Grotto
Page - 174
Networking
© Grotto Networking 2004
Diverse Paths via Pruning
Step 1. Find the
shortest path from
source to destination
Step 2. Prune out links
from the path of step
1.
NE
2
2
NE
1
2
1
NE
4
1
NE
3
2
2
NE
5
Grotto
Page - 175
Networking
© Grotto Networking 2004
NE
6
1
Diverse Paths via Pruning
Step 3. Can’t find another
path from 1 to 6 since we
just separated the graph
Hmm, maybe a solution
doesn’t exist? Or maybe
we need a new algorithm?
NE
2
2
NE
1
2
NE
4
NE
3
2
2
NE
5
Grotto
Page - 176
Networking
© Grotto Networking 2004
NE
6
Diverse Path Calculation Methods
Answer: Find a better
algorithm
2
NE
1
1
NE
2
NE
4
2
1
2
• Algorithms:
NE
3
NE
5
NE
6
1
2
– Bhandari’s method utilizing a modified Dijkstra
algorithm twice. [Ramesh Bandari, Survivable
Networks, Kluwer, 1999]
– Suurballe’s algorithm: transforms the graph in a way
that two regular Dijkstra computations can be
performed.
Grotto
Page - 177
Networking
© Grotto Networking 2004
Diverse Path Application Example
Our original diverse path via pruning network, revisited
with the diverse path algorithm. Cost path #1 = 5, cost
path #2 = 5, total cost 10. Which is 2/3 the previous
method.
NE
2
NE
8
2
8
2
2
NE
1
NE
4
1
NE
3
1
2
4
2
NE
5
NE
7
Grotto
Page - 178
Networking
NE
6
1
8
© Grotto Networking 2004
Shared Risk Concept
• Generalizing Link Diversity
–
–
–
–
Fiber/cable diversity
Conduit diversity
Right of way diversity
Geographic diversity
• Generalizing Node Diversity
–
–
–
–
Switching centers/Cos
Cities/Towns
Counties,
Geographic areas
Grotto
Page - 179
Networking
© Grotto Networking 2004
Network Optimization
– Example: with real world bandwidth constraints order
of connection set up via shortest path algorithm matters.
d
2
1
2
2
4
a
1
1
1
2
b1
2
5
2
3
Grotto
Page - 180
Networking
All links OC-48s,
assumed empty at start
2
c
(e) can't
allocate
© Grotto Networking 2004
Set up connections:
(a) NE 2 to NE 5: 1 STS-1
(b) NE 2 to NE 3: 1 STS-1
(c) NE 3 to NE 5: 1 STS-1
(d) NE 1to NE 4: 1 STS-48c
(e) NE 1 to NE 5: 1 STS-48c
Can't allocate
Network Optimization
– Example: with a change in connection request order all
requests can be satisfied.
a
2
2
2
1
4
All links OC-48s,
assumed empty at start
1
1 c
1
d 1
e
2
e
2
5
2
3
2
b
Grotto
Page - 181
Networking
© Grotto Networking 2004
Set up connections:
(a) NE 1to NE 4: 1 STS-48c
(b) NE 1 to NE 5: 1 STS-48c
(c) NE 2 to NE 5: 1 STS-1
(d) NE 2 to NE 3: 1 STS-1
(e) NE 3 to NE 5: 1 STS-1
All connections satisfied
Network Optimization: Batch
Processing
• Concept
– Instead of optimally routing a single connection we
optimally route a batch of connections at the same time
subject to capacity constraints of the links.
• Trade offs
– Batch size – more connections in a batch the more
optimally we can use network resources but the more
difficult (computationally) to solve.
– Time over which we aggregate the batch. The longer
we wait the bigger the batch size but the longer time to
service turn up and revenue!
– Can existing connections be rerouted? (big difference
here between circuit switching and virtual circuit
switching).
Grotto
Page - 182
Networking
© Grotto Networking 2004
Batch Processing of Connections
• Multi-commodity flow problem
– Bandwidth constraints for each link
– Source-destination bandwidth demands (each
must be treated as a separate “flow”)
– Minimize overall cost for new batch of
connections
• Solved via Linear Programming Techniques
– Optimization equation and link constraint
equations.
Grotto
Page - 183
Networking
© Grotto Networking 2004
Mathematical Optimization
Formulation
Example: Shortest Path (simple case)
Given a directed graph with link weights ai , j we will let xi , j the amount
of flow on link (i, j ) from node i to node j.
Minimize:
( i , j )A
ai , j xi , j
Non-negativity constraint for the flow variables:
xi, j 0, (i, j) A
At the source node we have:
xs, j xi,s bs
( s , j )A
(i , s )A
At the destination node we have:
xd , j xi,d bs
At intermediate nodes, i, we have:
xi, j
Grotto
Page - 184
Networking
j ,(i , j )A
( d , j )A
j ,( j ,i )A
( i ,d )A
x j ,i 0, i V , i s, d
© Grotto Networking 2004
Mathematical Formulation Example
• Shortest path:
– 13 links 13 flow variables in optimization
– 13 link constraints and 7 node balance constraints (20
total)
– Easy to see why Dijkstra and Bellman Ford are
preferred!
2
NE
2
NE
4
2
2
4
1
NE
7
NE
1
1
NE
5
2
2
2
2
2
NE
3
Grotto
Page - 185
Networking
NE
6
2
© Grotto Networking 2004
2
Multi-Commodity Formulation
– Since the connections are unique between each sourcedestination pair, we need to consider each connection as
a separate "commodity" in our model.
We will deal with the flow variables xi, j (k , m) where (i, j ) A , ranges
over the links in the network and (k , m) ranges over all the sourcedestination pairs for which we will be setting up batch connections.
– This gives us (number of links)*(number of
connections flow variables)
– We’ll have N*(number of connections) node balance
equations
– And we’ll have (number of links) capacity constraint
equations
Grotto
Page - 186
Networking
© Grotto Networking 2004
Multi-Commodity Flow: Sizing
NE
2
2
2
2
NE
4
1
3
NE
1
1
3
3
1
4
1
NE
3
1
NE
5
• Variables
– 4 bi-directional connections, 7 bi-directional links 112
Variables
• Constraints
– 14 unidirectional link constraints
– 40 node balance equations
Grotto
Page - 187
Networking
© Grotto Networking 2004
GMPLS/G.ASON Application
Examples
• Dynamic Data Services
• Inter-carrier Interoperability
• New Restoration and Service Options
Grotto
Page - 188
Networking
© Grotto Networking 2004
Flexible Data Services
Challenges
– Data traffic continues to become more prevalent on SONET
networks vs. TDM
– Carriers continuously seek to leverage their existing SONET/SDH
infrastructure
– Ethernet data rates (10, 100, 1000) MBps cannot be carried
efficiently over legacy SONET/SDH concatenated pipes, which are
either 155Mbps, 622Mbps, 2.5Gbps or 10Gbps
– Examples:
• 10Mbss Ethernet connection (10BT) transported over an STS1 (51.84
Mbps) link (20% efficiency)
• 100M Ethernet (100BT) over OC3 @ 155.52Mbps, 64% efficiency
• 2 x GbE over OC48 (80% efficiency)
– Changes in traffic patterns occur, generating need for dynamic
allocation of bandwidth
Grotto
Page - 189
Networking
© Grotto Networking 2004
Virtual Concatenation
– Defined in ITU-T G.707/2000
– Lets carriers allocate bandwidth within a SONET/SDH pipe to
different services
– Works at either the HOVC (STS-1, STS-3c, VC-3, VC-4) or the
LOVC (VT1.5, VT2, VT11, VT12) level
Grotto
Page - 190
Networking
© Grotto Networking 2004
SONET/SDH Concatenation Rules
– Fixed size concatenation blocks
– Contiguous blocks only
– Fixed starting points for blocks
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
(a) Empty STM-16 (OC-48) signal
VC-4-4c #1
VC-4
#1
VC-4
#2
VC-4
#3
VC-4
#4
VC-4
#5
VC-4
#6
VC-4
#7
12
VC-4-4c #2
(b) STM-16 (OC-48) signal with two VC-4-4cs (STS-12cs) and seven VC-4s (STS-3cs)
VC-4-4c #1
VC-4
#1
6
VC-4
#3
8
VC-4
#5
10
VC-4
#7
12
VC-4-4c #2
(c) STM-16 (OC-48) signal with two VC-4-4cs (STS-12cs) and four VC-4s (STS-3cs)
VC-4-4c #1
VC-4
#1
VC-4
#5
VC-4
#3
VC-4
#7
9
10
11
12
VC-4-4c #2
(d) Re-groomed STM-16 (OC-48) signal with two VC-4-4cs (STS-12cs) and four VC-4s (STS-3cs)
VC-4-4c #1
Grotto
Page - 191
Networking
VC-4
#1
VC-4
#5
VC-4
#3
VC-4
#7
VC-4-4c #3
VC-4-4c #2
(e) STM-16 (OC-48) signal with three VC-4-4cs (STS-12cs) and four VC-4s (STS-3cs)
© Grotto Networking 2004
Virtual Concatenation
– Virtual concatenation eliminates the size, contiguous blocks, and
starting point
– Furthermore virtually “concatenated” streams can be split across a
number of STS1 channels and sent over diverse routes over the
network
– VC mappers at end-points handle the differential delay associated
as they reconstruct original GbE stream
• Typical devices support one or two frames of differential delays
internally and up to 50ms (+/- 25ms), which is equivalent to 10,000
km difference in route length
STS-1 #1
STS-1-2v
Grotto
Page - 192
Networking
STS-1 #2
© Grotto Networking 2004
Link Capacity Adjustment Scheme
– Developed by ANSI T1X1.5 and ITU-T SG15 to automate
– Allows for dynamic increase/decrease in the number of components
in a VC group
– Increases flexibility of VCs by dynamically reconfiguring the VCs
distributed data packets
– Hitless switching for ordinary operations
– Allows for fast recovery in the case of a failed component.
Grotto
Page - 193
Networking
© Grotto Networking 2004
LCAS
GbE #1
GbE #2
GbE #1
GbE #2
End
Node
End
Node
Bandwidth scheduling for peak/SAN/back-up/etc…
Customers can have varying pipe size during course of day
Reprovisioning capabilities based on connectivity checks
Grotto
Page - 194
Networking
© Grotto Networking 2004
Issues with VCAT/LCAS
• VCAT/LCAS works at SONET path layer
– Says nothing about how components signals are
established.
– LCAS adds or removes component signals for
VCAT processing it does not setup or teardown
the signals across a network.
• How do we set up VCAT components in a
dynamic manner?
– Use the Optical control plane!
Grotto
Page - 195
Networking
© Grotto Networking 2004
Inter-Carrier Interoperability
• Can GMPLS/G.ASON be used between
distinct carriers? Yes
• Can it be used for data services? Yes
• Can GMPLS/G.ASON be use across
continents? Yes
• Can the control plane be tested separate
from the data plane? Yes
• Sure, but when will we see it? June 22-24, 2004
Grotto
Page - 196
Networking
© Grotto Networking 2004
OIF World Interoperability Demo
• Seven Carriers on three continents
– Asia: China Telecom, KDDI, NTT
– Europe: Deutsche Telecom, Telecom Italia
– North America: AT&T, Verizon
• Fifteen different vendors
– Alcatel, ADVA, Avici, Ciena, Cisco
– Fujitsu, Lucent, Mahi, Marconi, NEC
– Siemens, Sycamore, Tellabs, Turin
Grotto
Page - 197
Networking
© Grotto Networking 2004
OIF World Interop Demo 2004
Grotto
Page - 198
Networking
© Grotto Networking 2004
What was demonstrated?
• Signaling
– OIF UNI v1.1 which is derived from ITU-T
G.7713.2
– OIF E-NNI which is derived from ITU-T
G.7713.2
• Routing (topology & resource status
dissemination)
– OIF E-NNI routing based on G.7715
architecture and G.7715.1 requirements
• Flexible data capabilities
– Via GFP, VCAT and LCAS
Grotto
Page - 199
Networking
© Grotto Networking 2004
How was it demonstrated?
• The Signaling Communications Network (SCN)
– that carries control plane protocol messages between
carrier sites was established using IPSec tunnels
transported over the public Internet.
• Supported a combination of real and simulated
transport links
– Real transport links connected equipment within each
carrier lab
– A real trans-oceanic VC-4/OC-3 link connected three of
the carrier labs
– Simulated transport links were used between other
carriers, due to the expense and lead time required for
real transport links.
Grotto
Page - 200
Networking
© Grotto Networking 2004
OIF World Interop demo 2004
• For more information see:
– James D. Jones, Lyndon Ong, Monica Lazer,
“Creating an Intelligent Optical Network
Worldwide Interoperability Demonstration”,
IEEE Communications Magazine, November
2004.
– Hans-Martin Foisel, “Optical Internetworking
Forum: World Interoperability Tests and
Demonstrations”, ECOC Stockholm 2004.
Grotto
Page - 201
Networking
© Grotto Networking 2004
Restoration and the Control Plane
Criteria for selecting a protection/restoration
method
• Reliability/Robustness
• Bandwidth Efficiency
• Recovery Time
Grotto
Page - 202
Networking
© Grotto Networking 2004
Reliability/Robustness
• Failure types that are restorable
– One line out recoverable (laser failures)
– Conduit cuts
– General failures
• Implementation Complexity
– More complex the scheme the lower the
probability it will work when needed
• Distributed vs. Centralized
– Distributed schemes are more robust but may
be more complex
Grotto
Page - 203
Networking
© Grotto Networking 2004
Bandwidth Efficiency
• Network Structure
– General mesh network structures generally permit
higher bandwidth efficiency as opposed to linear or ring
structures
• Bandwidth Granularity
– If not all connections must be protected than protecting
at the finest granularity possible yields best bandwidth
efficiency.
• Distributed vs. Centralized
– Centralized algorithms that run on servers have a better
capability to optimize for bandwidth efficiency,
however centralized is less robust.
Grotto
Page - 204
Networking
© Grotto Networking 2004
Recovery Time
• Network size and geographic extent
– Can’t change the speed of light!
• Local vs. End to End restoration
– Local can be faster, end to end more bandwidth
efficient
• Method used to find alternative routes
– Pre-computed routes faster but less robust
• Bandwidth reservation vs. coordination time
– Reserving protection bandwidth saves time but is less
bandwidth efficient
Grotto
Page - 205
Networking
© Grotto Networking 2004
The 50mS Myth
Call Potentially
Dropping (All
FCC
Circuit
Reportable
Switched
Network
Major Social/
Services)
Potential
Congestion
PL
Business
Packet
Voiceband
Minor
Social/
Impacts
Disconnects
Service Outage Impact Disconnects
(X.25)
Business
Potential
Disconnects impacts
(<5%)
Packet
May Drop
Data Session
Trigger
(X.25)
Changeover Voiceband
Disconnects Timeouts
Calls
of CCSN
Potential
Depending
STP
Data Session f
on Channel
Signaling
Timeouts
Bank
Links
Vintage
Effect Cell
UnRerouting
4th
Service "hit" Process
acceptable
Undesirable
3rd
Restoration
(reframes)
2nd
Restoration
Target
1st
Restoration
Target
Range
Restoration
Target
Range
Protection
Target
Range
Switching
Range
Range
0
50 ms
200 ms
2s
10 s
5 min
30 min
Restoration Time
(After Detection of Failure)
Circa 1994 from Sonosky, JSAC, Jan 1994
Grotto
Page - 206
Networking
© Grotto Networking 2004
Example #1: Linear 1+1
Same signal is sent
on both lines
Bandwidth
Efficiency?
Robustness?
Working #1
Timeliness?
Network Element
A
Network Element
B
Protection #1
Grotto
Page - 207
Networking
Receiver chooses
the best of the two
© Grotto Networking 2004
Example #2: Linear 1:N
Working lines each consist of a bi-directional pair of fibers
Bandwidth
Efficiency?
Working #1
..
.
Network Element
A
Working #N
Robustness?
Network Element
B
Protection #1
Protection line consists of a bi-directional pair of fibers
Grotto
Page - 208
Networking
© Grotto Networking 2004
Timeliness?
Example #3: 2/4F-BLSR
1
24
25
48
1
24
25
48
NE
B
NE
A
Bandwidth
Efficiency?
Robustness?
Timeliness?
2F-BLSR
(OC-48 lines)
NE
D
Bi-directional STS-12c
connection between
nodes A and D
Grotto
Page - 209
Networking
1
24
25
48
Bi-directional STS-12c
connection between
nodes A and B
1
24
25
48
1
24
25
48
1
24
25
48
NE
C
1
24
25
48
Reserved for Protection
1
24
25
48
Reserved for Protection
© Grotto Networking 2004
Source re-route Mesh
Leveraging GMPLS/G.ASON to give us a more robust and
bandwidth efficient restoration mechanism at little
incremental cost
• Routing (topology/resource status
dissemination)
– Gives each node timely information on the
currently available portion of the network
• SPC Model and Signaling
– Allows source nodes to initiate alternative path
in the event of a outage to a circuit.
Grotto
Page - 210
Networking
© Grotto Networking 2004
Source re-route Mesh example
SPC owner
SPC owner
Grotto
Page - 211
Networking
© Grotto Networking 2004
Source re-route Mesh example
SPC owner
SPC owner
Grotto
Page - 212
Networking
© Grotto Networking 2004
Protection Summary
Name
Restoration
time
Bandwidth
Required
Failure Robustness
1+1 Linear
(SDH/SONET)
Typically under
50 mSec
2x
Only as good as the diversity
of the alternative paths. One
line out.
1:N Linear
(SDH/SONET)
Typically under
60mSec
Bi-directional
Line Switched
Ring (BLSR)
Typically under
100mSec
2x
Source reroute Mesh
Restoration
Depends on #
of circuits, # of
hops, prop.
delay
With d the
average
degree best
we can
achieve:d
Grotto
Page - 213
Networking
1 N
x
N
d 1
Only as good as the diversity
of the paths, one line out.
Good for laser failures.
Diversity built in, one line
out, except in 4F case which
can handle multiple span
failures. Good for fiber cuts.
Can recover any recoverable
situation, permits graceful
degradation if desired
x
© Grotto Networking 2004
Thank You!
Grotto
Page - 214
Networking
© Grotto Networking 2004