OSPF-TE extensions for OTN
(draft-ashok-ccamp-gmpls-ospf-g709-03)
Rajan Rao (rrao@infinera.com)
Ashok Kunjidhapatham (akunjidhapatham@infinera.com)
John Drake (jdrake@juniper.net)
Steve Balls (Steve.Balls@metaswitch.com)
Khuzema Pithewan (kpithewan@infinera.com)
Snigdho Bardalai (sbardalai@infinera.com)
Biao Lu (blu@infinera.com)
CCAMP
IETF-80 (Mar-2011)
Outline
•
•
•
•
Update Summary
Path Computation – what we need
Existing solutions looked at
The Model
– Examples
– Encoding details
• Summary & Next Steps
• Comments & Response
Update Summary
1. Moved away from single ISCD to multiple ISCDs
– One ISCD per ODU rate (as discussed in Beijing)
2. Identified new requirements
– Muxing restrictions & service creation
– Induced FAs & OTN multiplexing hierarchy
– Consistency with RFC6001
3. Non OTN signal transport
– Address ‘Termination’ capability for non-OTN transport over ODUs
• E.g. terminate ODU and extract Ethernet for packet switching at every node
3
Path computation – what is required
Unbundled Te-Links
Bundled Te-links
Typical use cases
ISCDs
Mux/Dmux
info (IMCD)
ISCDs
Mux/Dmux
info (IMCD)
LSP w/o FA
Y
N
Y
N
LSP with Manual FAs
Y
N
Y
N
VCAT w/o FA
Y
N
Y
N
VCAT with Manual FAs
Y
N
Y
N
nxLSPs w/o FA
Y
N
Y
N
LSP with induced FA
Y
Y
Y
Y
VCAT with induced FA
Y
Y
Y
Y
nxLSPs with induced FA
Y
Y
Y
Y
LSP for non OTN client transport
Y
Y
Y
Y
(e.g. Pkt switching at every node with ODU termination)
New challenges to address
Existing Mechanisms - Inadequate
Role of IACD:
– According to RFC 5212, IACD represents internal BW
• Two independent switch fabric model
• Relationship between only TWO layers/interfaces
– We need to address the following for OTN muxing hierarchy
• Single switch fabric for all ODUs
• Multiple Layer (>2) relation, Muxing restrictions & disparities
– e.g . ODU2-ODU1-ODU0
Detection of LSP Regions:
– Extend RFC-4206 definition to OTN mux layers
• ISCD1 < ISCD2
– RFC-4202 (section 2.4.7) to cover differences at two ends of Te-Link
• Doesn’t work as ISCDs advertised depend on what is switchable on the link
(refer to slides #17)
What is new
• Existing mechanisms inadequate
– To capture Mux/Dmux information
– To detect FA boundaries based on Switching Capabilities
• The proposal:
– Use ISCDs for advertising switching BW per ODU rate
– Define a new sub-TLV (under Link TLV) to advertise
• Mux/Dmux information
• BW corresponding to root ODU
6
The Model
• Use ISCDs to advertise ODUj (j<=k) Switching BW
• Use IMCDs to advertise ODUj (j<=k) Termination BW
– E.g. BW adv for GPID = ODU4-ODU3-ODU2 corresponds to ODU4 ‘Termination’
• IMCD is required for induced FA creation in MLN
– includes Single & Multi Stage Multiplexing networks
– IMCD advertisement is optional
• There could be multiple ISCDs and IMCDs advertised per interface
– ISCD for each switchable ODUj rate (j<=k)
– IMCD for each multi-layered OTN G-PID
• The IMCD concept can be extended to any multi-layered network
Example-1: Advertisement when no FA is required
•
•
•
Multiplexing Hierarchy shown is same at both ends of Te-Link
Advertise all switchable ODUjs irrespective of the hierarchy (j<=k)
If FA is not needed, then IMCD advertisement is NOT required
–
E.g. - BW adv for red, blue & green links include ISCDs for ODU2, ODU1 & ODU0 as follows
ISCDs Adv
ISCD1
ISCD2
ISCD3
Main ISCD
ODUj BW sub TLV in SCSI
Max LSP BW
(bytes/sec for 8 prio)
ODU2 Nominal rate
ODU1 Nominal rate
ODU0 Nominal rate
Available ODUj(s)
for 8 prio
1
4
8
8
Example-2: Advertisement to support FA
•
•
Advertise all switchable ODUjs irrespective of the hierarchy (j<=k ) as before
Advertise IMCDs to support FA creation:
–
–
IMCD for ODU2 termination at A, B, C & D
IMCD for ODU1 termination at B, C & D
Adv by A & B for A-B/B-A
IMCDs
G-PID
IMCD1 ODU2-ODU1
IMCD2 ODU2-ODU0
Available
termination
BW for 8 prio
1
1
Adv by B & C for B-C/C-B
IMCDs
IMCD1
IMCD2
IMCD3
IMCD4
G-PID
ODU2-ODU1
ODU2-ODU0
ODU1-ODU0
ODU2-ODU1-ODU0
Available
termination
BW for 8 prio
1
1
4
1
Can be used to create ODU1-FA to switch ODU0s
Adv by C & D for C-D/D-C
Available
termination
G-PID
BW for 8 prio
ODU2-ODU1
1
ODU2-ODU1-ODU0
1
ODU1-ODU0
4
IMCDs
IMCD1
IMCD2
IMCD3
9
New Sub-TLVs for OTN
(G.709–v3)
ISCD with new Switching Capability
ODUk Switch Capability Specific Information (SCSI)
IMCD sub TLV
• Multiple IMCDs, one per G-PID (mux branch)
• Applicable to fixed ODUjs only (j <=k)
– i.e. parent in any G-PID is always a fixed ODUj
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
G-PID
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 2
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 3
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 5
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 6
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Available ODUj count at Prio 7
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Possible to include parent info if required in future in Reserved field
• The structure is similar to ISCD. We could add technology specific
extensions (similar to SCSI in ISCD) if required
• Can be extended to any multi-layered network
Summary & Next Steps
• ISCDs are sufficient for ODU service creation
– Covers VCAT & nxLSP creation
•
•
•
•
•
•
•
•
ITCD(s) mandatory if inducing FA is necessary
Multiple ISCDs, one per ODUj/ODUflex
Multiple IMCDs, one per HO-ODUj (J<=k) terminable
No correlation among ISCDs
No correlation among IMCDs
The proposal provides complete solution
Would like to take to next level – WG doc
IMCD is applicable to any ML network, propose to cover in a
separate draft
Comments & Response
Steve/Xihua: Why IMCD is not present for ODU2-ODU1-ODU0 in example#2
•
Resp: Should be there. Will include.
Fatai: Why do we need IMCD for ODU1-ODU0
•
Resp: This is required to support FAs at ODU1 layer on OTU2 interface (ref to
slide#22 for an e.g.)
Lou: Sections 3.x requires cleanup. What should come before how.
•
Resp: Agree, we will clean up this section.
Steve: Use of priority in examples: clarify if ‘P’ means only one priority or is it ‘Pi’
•
Resp: Agree. We will update the examples to show it is ‘Pi’.
Curtis: The sub-TLV type and G-PID should be listed as TBD
•
Resp: Agree. We will update the draft.
Backup Slides
What ISCDs to advertise
•
A-end:
–
–
•
ISCDs :
• ODU2= 1
IMCDs
• ODU2-ODU1=1
• ODU1-ODU0 = 4
• ODU2-ODU1-ODU0 = 1
B-end:
–
–
ISCDs :
• ODU2= 1
IMCDs
• ODU2-ODU0=1
– We can not use ISCDs (RFC 4206 based) to determine ODUj boundaries/LSP regions
– We need more than 2 layer relation to support service creation (via FA(s) )
Why just 2 layer information is not sufficient: example-1
• Node-Y in both cases will advertise these IMCDs:
• IMCD1: ODU2-ODU1 = 1
• IMCD2: ODU1-ODU0 =1
– The above IMCDs doesn’t mean ODU2-ODU1-ODU0 is possible
– We need ODU2-ODU1-ODU0 =1 (IMCD3) to support ODU0-LSPs in
the first config
Why just 2 layer information is not sufficient: example-2
(Bundling dissimilar)
Link bundle with dissimilar muxing capabilities: Layer relation
• In this example, we need two FAs to originate from the same point (at node-B).
• It is necessary to advertise IMCD3 as we can not conclude full mux
• relation from IMCD1 & IMCD2.
A---------B---------C--------D-------E
|------ODU2-FA---|
|------ODU1-FA-----------|
|----------------ODU0-LSP------------|
Link A-B: Hierarchy at both ends is OTU2-ODU2-ODU0
Link B-C: Is a bundled Te-link with 3 component links with
multiplexing hierarchy at both ends as shown:
Why just 2 layer information is not sufficient: example-2 cont’d
(Bundling dissimilar)
•
•
•
Component link#1: OTU2 link with mux hierarchy: OTU2-ODU2-ODU1-ODU0
Component link#2: OTU2 link with mux hierarchy: OTU2-ODU2-ODU1
Component link#3: OTU1 link with mux hierarchy: OTU1-ODU1-ODU0
Link C-D:
- Hierarchy at C end is OTU2-ODU2
- Hierarchy at D end is OTU2-ODU2-ODU1
Link D-E:
- Hierarchy at D end is OTU1-ODU1
- Hierarchy at E end is OTU1-ODU1-ODU0
The IMCDs advertised for B-C would include the following:
IMCD1:
G-PID = ODU2-ODU1
Available HO-ODUj count at Pi = 2 (ODU2) after LC#1 used up = 1
IMCD2:
G-PID = ODU1-ODU0
Available HO-ODUj count at Pi = 5 (ODU1) after LC#1 used up = 1
IMCD3:
G-PID = ODU2-ODU1-ODU0
Available HO-ODUj count at Pi = 1 (ODU2)
We can’t correlate among IMCD1 & IMCD2 and conclude ODU2-ODU1-ODU0
Te-Link with different Switching/Termination Capabilities
(why RFC4206 is not adequate)
FA-LSP boundary detection:
• Node-A uses ISCD & Mux-Demux info from B to determine FA boundary/need
–
•
ODUj Layer boundary, LSP region (extensions to RFC 4206, section 5.0)
–
–
–
•
Node-A::ODU0-ISCD < Node-B:: ODU2-ISCD
The above order determines layer boundaries & potential FA boundary nodes
This won’t work as there is no ODU0-ISCD at node-A.
ISCD and labels (extensions to RFC 4202, section 2.4)
–
–
•
Creation of ODU0 client-LSP triggers detection of FA-boundary node(s)
[ODU0, ODU2] - a link between different ODUj layers
This is on similar lines to [PSC, TDM] relation in RFC 4202
Generalization:
–
[ODUj, ODUj+1] - a link between different ODUj layers
• [ODUj, ODUj+1] – label represents ODUj+1 time slots (FA layer label)
21
Termination BW for layers other than ODUk
•
Opt#1: ODU3-FA
– Locks up bigger pipe between two nodes, in-efficient
– scaling issues if P2P ODU3-FAs are used
•
Need a generic solution for FA creation at any HO-ODU layer
– Solution should provide a way to create ODU2-FA in this e.g. (see opt#2)
– Requires an IMCD with this info
•
ODU2-ODU0 = 4 (ODU2 Termination BW as opposed to ODU0 switching BW
New Requirements
(What are we trying to address)
Focused on building architectural support in the model :
1. To identify FA boundary nodes
a) Should cover origination and termination of FAs
b) Should cover inducing FA(s) at ODUk layer
c) Should cover inducing FA(s) at any HO-ODUj layer(s) (j < k)
2. To identify what ODUj(s) can be extracted after termination of
ODUk and/or HO-ODUj layers(s)
–
Also cover non-OTN cases (e.g. Ethernet over GFP over ODU)
3. To support bundling of links with similar muxing hierarchy
4. To support bundling of links with dissimilar muxing hierarchy
5. Role of LMP in support of the above
Mux branch identification: proposed G-PID values
• New values defined in addition to those defined in RFC 3471 & RFC 4328
• Table below shows G-PID combinations for ODU0 within in an ODU4
Value
suggested
G-PID
The meaning
60
ODU4-ODU0
Termination of ODU4 required for ODU0 switching. BW advertised is
number of ODU4 terminations possible at the interface
61
ODU4-ODU3-ODU0
Termination of ODU4 & ODU3 required for ODU0 switching. BW advertised is
number of ODU4 terminations possible at the interface
61
ODU4-ODU3-ODU2-ODU0
Termination of ODU4, ODU3 & ODU2 required. BW advertised is number of
ODU4 terminations possible at the interface.
63
ODU4-ODU3-ODU2-ODU1-ODU0
Termination of ODU4, ODU3, ODU2 & ODU1 required. BW advertised is
number of ODU4 terminations possible at the interface
………………………..
75
ODU3-ODU2
Termination of ODU3 required. BW advertised is number of ODU3
terminations possible at the interface
76
ODU3-ODU0
Termination of ODU3 required. BW advertised is number of ODU3
terminations possible at the interface
77
ODU2-ODU0
Termination of ODU2 required. BW advertised is number of ODU2
terminations possible at the interface
78
ODU3-ODU3-ODU0
Termination of ODU3 & ODU2 required. BW advertised is number of ODU3
terminations possible at the interface
……………………….. (other G-PID values for ODU1, ODU2, ODU2e, ODUflex, etc)