1 / 9

GMPLS Asymmetric Bandwidth Bidirectional LSPs draft-berger-ccamp-asymm-bw-bidir-lsps-00.txt

GMPLS Asymmetric Bandwidth Bidirectional LSPs draft-berger-ccamp-asymm-bw-bidir-lsps-00.txt. Lou Berger <lberger@labn.net> Attila Takacs <attila.takacs@ericsson.com> Diego Caviglia <diego.caviglia@ericsson.com> Don Fedyk <dwfedyk@nortel.com> Julien Meuric <julien.meuric@orange-ftgroup.com>.

finn-burris
Download Presentation

GMPLS Asymmetric Bandwidth Bidirectional LSPs draft-berger-ccamp-asymm-bw-bidir-lsps-00.txt

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. GMPLS Asymmetric Bandwidth Bidirectional LSPsdraft-berger-ccamp-asymm-bw-bidir-lsps-00.txt Lou Berger <lberger@labn.net> Attila Takacs <attila.takacs@ericsson.com> Diego Caviglia <diego.caviglia@ericsson.com> Don Fedyk <dwfedyk@nortel.com> Julien Meuric <julien.meuric@orange-ftgroup.com> CCAMP - 69th IETF

  2. Background • Asymmetric LSP Bandwidth is actually an old discussion (role reversal time!) • From: Adrian Farrel <AF@dataconnection.com>To: mpls@UU.NETSubject: Asymmetrical Bi-directional LSPsDate: Wed, 27 Sep 2000 22:33:57 +0100 • Conclusion at that time: no real need for such LSPs • Trigger for draft • Raised in PBB-TE context • Discussed in draft-takacs-asym-bw-lsp-00.txt CCAMP - 69th IETF

  3. Draft Objective • As this conversation keeps resurfacing, we propose that the WG determine and document: • The preferred way to provide this function • Should this be a standard or experimental function CCAMP - 69th IETF

  4. Proposed Solutions • Draft covers two approaches: • Both versions use a single bidirectional LSP • Technology specific • Uses ADSPEC to carry traffic parameters for upstream data • Requires MEF Ethernet Traffic Parameters • Generic • Defines new upstream traffic parameter related object classes to match old downstream objects  Propose that WG select and pursue one approach CCAMP - 69th IETF

  5. Some Context • RFC2205 (RSVP) and RFC3209 (RSVP-TE) • Data flow –Ingress  Egress • SENDER_TSPEC –Ingress desired transmission characteristics • FLOWSPEC –Egress desired receive/downstream QoS • ADSPEC –What is being provided by network* • RFC3473 (GMPLS-RSVP-TE) • Data flow –Ingress  Egress • SENDER_TSPEC –Desired QoS for both upstream and downstream • FLOWSPEC –Confirmation of allocated resources • ADSPEC –Unmodified in general – note none for upstream, unused for some specific technologies |---| Path |---| | I |----------------->| E | | n | -SENDER_TSPEC | g | | g | -ADSPEC | r | | r | | e | | e | Resv | s | | s |<-----------------| s | | s | -FLOWSPEC | | |---| |---| Data Flow -----------------------> |---| Path |---| | I |----------------->| E | | n | -SENDER_TSPEC | g | | g | -ADSPEC | r | | r | | e | | e | Resv | s | | s |<-----------------| s | | s | -FLOWSPEC | | |---| |---| Data Flow <----------------------> CCAMP - 69th IETF

  6. Option 1: Technology Specific |---| Path |---| | I |----------------->| E | | n | -SENDER_TSPEC | g | | g | -ADSPEC | r | | r | | e | | e | Resv | s | | s |<-----------------| s | | s | -FLOWSPEC | | |---| |---| • Per technology solution • Draft defines Ethernet specific solution • ADSPEC carries upstream traffic parameters • Draft requires MEF Ethernet Traffic Parameters • Solution only compatible with technologies that don't require/use ADSPEC • SENDER_TSPEC and FLOWSPEC per RFC2205/3209 CCAMP - 69th IETF

  7. Option 2: Generic |---| Path |---| | I |------------------->| E | | n | -SENDER_TSPEC | g | | g | -ADSPEC | r | | r | -UPSTREAM_FLOWSPEC | e | | e | | s | | s | Resv | s | | s |<-------------------| | | | -FLOWSPEC | | | | -UPSTREAM_TSPEC | | |---| -UPSTREAM_ADSPEC |---| • New upstream objects to match RFC2205 downstream objects • UPSTREAM_FLOWSPEC –Ingress desired receive/upstream QoS • UPSTREAM_TSPEC –Egress desired transmission characteristics • UPSTREAM_ADSPEC –What is being provided by network* • Draft missed handling of UPSTREAM_TSPEC / UPSTREAM_FLOWSPEC mismatches • Next rev will state to use MBB CCAMP - 69th IETF

  8. Opt. 1: Tech. Specific Pros: Simple to implement, i.e., no message format changes Cons: Need change per technology Precludes original use of ADPSEC Only works with technologies that don’t require ADSPEC Opt. 2: Generic Pros: Works with any technology Fixes omission of Upstream ADSPEC introduced in RFC3473 Cons: Three new object classes Alternatives Summary CCAMP - 69th IETF

  9. Next Steps • Answer major questions: • Technical direction: • Per technology solutions (Ethernet today) • Generalized solution • Process direction: • If required functionality  Standard • If not  Experimental • General draft update • Other comments? CCAMP - 69th IETF

More Related