1 / 8

Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls

Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls. Dimitri Papadimitriou and Adrian Farrel draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt. What happened to the old draft?. Old draft was draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt Covered too much material

cfontanez
Download Presentation

Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls Dimitri Papadimitriou and Adrian Farrel draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt 65th IETF Dallas March 2006

  2. What happened to the old draft? • Old draft was draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt • Covered too much material • Requirements • Applicability • Solutions • Issues with other UNI specs • Call extensions • Decided to rationalise • Generic call support (this I-D) • ASON applicability (next agenda slot) 65th IETF Dallas March 2006

  3. What is a Call? • An association between endpoints • Possibly also between key transit points (such as network boundaries) • Supports of an instance of a service • Call - The end-to-end association • Call Segment - The association between two transit points or between an endpoint and a transit point • Call Manager - An entity that processes a Call or Call Segment 65th IETF Dallas March 2006

  4. Why do we care? • Often we don’t care! • LSPs can be operated happily without calls • Calls provide supplementary function in GMPLS networks • When might we need a call? • Coordinating multiple LSPs when additional information is needed above simple association • Service and access negotitation • Reverse direction unidirectional LSP? • VCAT/LCAS? • ASON 65th IETF Dallas March 2006

  5. What we don’t do • Piggy-backing call on LSP signaling • Prevents “empty call” • Makes multiple LSPs per call ambiguous • Makes diversely routed LSPs ambiguous • Places call state within the network • Not processed within the network, but… • State is held and forms part of RSVP-TE soft state • RSVP-TE is not a transport protocol! 65th IETF Dallas March 2006

  6. What we do • Use the Notify message to establish call • Directly routed (between Call Controllers) • Does not establish Path state • Confirmed by Message_ID • Carry • Indication that this is a Call • Administrative Status object • Call ID • Session object (in the Notify message) • Use of reserved field for “short form” • Use of Session Name for “long form” • Link Capability object • Link bundling attributes • Bandwidth in TSpec (may be greater than any associated LSP) • Policy object can be used • Other objects TBD for specific future applications 65th IETF Dallas March 2006

  7. Associating LSPs with a Call • Currently proposing matching Session object • Including match of previously reserved field • Alternative • Association object • Defined for e2e recovery and used elsewhere • Either way can have: • LSPs without a call • Call without LSPs • One or more LSPs per call • Unidirectional (and reverse direction) LSPs in a call 65th IETF Dallas March 2006

  8. Next Steps • Implementation exists • Was previously a CCAMP draft • Bring it into the working group • Review and complete quite soon 65th IETF Dallas March 2006

More Related