1. CCAMP - 69th IETF GMPLS Asymmetric Bandwidth Bidirectional LSPs draft-berger-ccamp-asymm-bw-bidir-lsps-00.txt Lou Berger Attila Takacs Diego Caviglia Don Fedyk Julien Meuric

2. CCAMP - 69th IETF Background Asymmetric LSP Bandwidth is actually an old discussion (role reversal time!) From: Adrian Farrel To: mpls@UU.NET Subject: Asymmetrical Bi-directional LSPs Date: 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

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

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

5. CCAMP - 69th IETF 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

6. CCAMP - 69th IETF Option 1: Technology Specific 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 |---| Path |---| | I |----------------->| E | | n | -SENDER_TSPEC | g | | g | -ADSPEC | r | | r | | e | | e | Resv | s | | s |<-----------------| s | | s | -FLOWSPEC | | |---|

7. CCAMP - 69th IETF Option 2: Generic 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 |---| 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 |---|

8. CCAMP - 69th IETF Alternatives Summary 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

9. CCAMP - 69th IETF 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?