gmpls signaling extensions for g 709 v3 draft khuzema ccamp gmpls signaling g709 00 txt n.
Skip this Video
Loading SlideShow in 5 Seconds..
GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt ) PowerPoint Presentation
Download Presentation
GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt )

Loading in 2 Seconds...

play fullscreen
1 / 15

GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt ) - PowerPoint PPT Presentation

  • Uploaded on

GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt ). Rajan Rao ( ) Khuzema Pithewan ( ) Ashok Kunjidhapatham ( ) Mohit Misra ( ). Outline. Goals Proposal

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt )' - aaron-martinez

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
gmpls signaling extensions for g 709 v3 draft khuzema ccamp gmpls signaling g709 00 txt

GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt )

Rajan Rao ( )

Khuzema Pithewan ( )

Ashok Kunjidhapatham ( )

Mohit Misra ( )

  • Goals
  • Proposal
  • Discussion items
  • Advantages & Comparison
  • Backup

A model to support signaling for:

  • Fixed size ODU containers (G.709-v1 & v3)
  • Flexible ODU containers
  • Different Time-Slot granularities (1.25G & 2.5G)
  • Complete muxing hierarchy of G.709-v3
  • VCAT services
  • Potential evolution of OTN standards

New Label Format defined to:

  • Encode TSs as bit map
  • Allow specification of complete muxing hierarchy (G.709-v3)
  • Support TS-Granularities & TPN

Extensions to RFC-4328: G.709 traffic params redefined

    • Tolerance encoded in NMC field
    • Bit-rate encoded in reserved field
new label format for otn
New Label Format for OTN

Generalized Label Format

proposed extensions to rfc 4328
Proposed Extensions to RFC-4328

G.709 Traffic Parameters (TSPEC)

NMC/Tolerance :

  • NMC is Used only with the Old Label Format (Backwards Compatibility)
  • For ODUflex SignalType, this field is interpreted as Tolerance


  • Used only for ODUflex SignalType
  • For other signal types it is set to zero and not interpreted on the receiving nodes
  • Simple network with varying muxing levels
  • Link A-B: ODU0 directly supported over ODU2
  • Link B-C: ODU0 supported over ODU3 over ODU4
  • Link C-D: ODU0 directly supported over ODU2
  • There is no ODU3-LSP (FA) created between B-C
example cont d
Example cont’d
  • ODU0 service requested from node-A to node-D
  • Nodes B & C know they need ODU3 layer to support ODU0 (local matter)
    • B & C advertise ODU0 BW as per - draft-ashok-ccamp-gmpls-ospf-g709-02.txt
  • Labels exchange as follows:
    • A-B: Label for ODU0
    • B-C: Label with complete info for ODU3 and ODU0
    • C-D: Label for ODU0
  • There is no ODU3-LSP (FA) created as a result of the above service
discussion items 1
Discussion Items (1)
  • Question-1: Multi-stage is not present at all as requirement/feature in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress (Fatai’s comment)
    • Authors didn’t agreed to the comment
    • Our interpretation of G.709-v3 is full hierarchy support is required (ref Fig-7-1A)
    • We agree with Deborah’s comments on NOT restricting GMPLS solution to a single stage
  • Question-2: Generalized Label Request cannot be changed during signaling path (Fatai’s comment)
    • Clarified that it doesn’t change and only the labels that change on a hop by hop basis
    • It is fully consistent with RFC-3471, RFC-4328
  • Question-3: …One or more ODU2 LSPs need to be created between B and D in order to support the A-E ODU0 LSP. where are the parameters associated with establishing the ODU2 carried? (John’s comment)
    • Clarified with an example that the model is not based on FA approach
    • Clarified that intermediate LSPs are NOT created to support service at different muxing levels
discussion items 2
Discussion Items (2)
  • Question-4: An amazing "idea", but it will totally destroy the basic principle of GMPLS (RSVP-TE) (Fatai’s comment)
    • Authors don’t believe there is any violation of GMPLS
    • Requested for clarification on what is broken
  • Question-5: You are advertising ODU0 services on ODU3s that do not support them.   That isn’t consistent with the GMPLs architecture (John’s comment)
    • Authors don’t believe there is any violation of GMPLS
    • Muxing hierarchy can be addressed without MLN
      • like Sonet/SDH label as per RFC-3946. E.g muxing VT into STS-n doesn’t mandate FA
    • This model doesn’t prevent use of MLN
advantages comparison
Advantages & Comparison


  • Addresses complete muxing hierarchy (G.709-v3)
  • Doesn’t require intermediate LSPs when OTN muxing levels are involved
  • Highly scalable solution (no FAs, smaller TE-DB)
  • Allows varying muxing levels on each segment seamlessly
  • Doesn’t prevent MLN deployments
  • Compact encoding scheme


  • Doesn’t address G.709-v3 muxing levels
  • Assumes MLN to support muxing hierarchy (FA approach)
  • Not scalable
limitations of rfc 4328
Limitations of RFC-4328
  • G.709 Traffic Parameters (TSPEC)
    • No support for new SignalTypes defined in G.709v3 – ODU0, ODU4, ODU2e and ODUflex.
    • ODUflexneeds Bit-Rate and Tolerance to be signaled instead of number of TSs.
    • NMC parameter is not valid for end-to-end Traffic Specification as number of TS required for ODUj could vary on different ODUks along the LSP path.
      • Eg: ODU2e requires 9 TS on ODU3 and 8 TS on ODU4.
  • Generalized Label Format
    • Not scalable for specifying large number of Timeslots (ODU4 requires 80 1.25G TSs and ODU3 requires 32 1.25G TSs).
    • Multi-stage multiplexing enforces hierarchical label format which is not supported in the current Label format.
    • No support for multiple TS Granularities (1.25G and 2.5G).
backwards compatibility
Backwards compatibility




Link A-B:

  • G.709-v1 version (2001) based OTUk link
  • TSG=2.5G;
  • Label format as per RFC 4328

Link B-C:

  • G.709-v3 version based OTUk link (12/09)
  • TSG=1.25G;
  • Used New label format proposed

Example: For an ODU2 connection going from A-C:

  • On link A-B : NMC=4 is applicable
  • On link B-C : NMC is not used;
    • # of TSs used is 8
    • Could involve multi-stage multiplexing – i.e. label for each mux layer
backwards compatibility interoperability with older version of signaling stack
Backwards compatibilityInteroperability with Older version of signaling stack
  • Neighbors should exchange their signaling stack version information ahead of service creation.
  • On a given span, if one of the neighbor is found to be running older version of signaling stack, Label format defined in RFC-4328 must be used.
  • If both the neighbors are running newer version of signaling stack, new Label format must be used.