Generalized MPLS RSVP-TE Signaling for Layer-2 LSPs

1. Generalized MPLS RSVP-TE Signaling for Layer-2 LSPs <draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt> D.Papadimitriou (dpapadimitriou@psg.com) D.Brungard (dbrungard@att.com) A.Ayyangar (arthi@juniper.net) M.Vigoureux (martin.vigoureux@alcatel.fr)

2. Summary • Extend introduction clarifying motivation for draft and relation to RFC 3471/73 • Generalized text to all RFC 3473 L2 technologies: ATM, FR, ETH, etc. • Detailed Generalized Label Request object processing and definition of new L2 SENDER_ TSPEC / FLOWSPEC object and processing • Detailed section on L2 Label value space, representation and encoding • Enhanced security section (see next slides)

3. Step-by-step • RFC3945 defines L2SC interface and support for L2SC LSP (RFC 3471/73 code-points) • <draft-papadimitriou-ccamp-gmpls-l2sc> • initial version focused on ETH port mode • generalize mechanisms for any L2 technology (add: ATM, FR) • however, ETH port mode too coarse (10 GbE PHYs)  refine resource reservation granularity (i.e. semantic) on L2SC links

4. Layer 2 Label Space • L2 labels representation (that can be supported over [X,L2SC], [L2SC,L2SC] and [L2SC,X] links) and assigned upon reception of the LSP Encoding and Switching Types: LSP Encoding type Switching Type Label ----------------- -------------- ----------------------------- Ethernet L2SC Port, VLAN ID ATM L2SC Port, VPI, VCI, VP Bundle ID Frame-Relay L2SC Port, DLCI • Ethernet, ATM, Frame Relay Port labels are 32 bits values • Ethernet VLAN ID labels are encoded with the VLAN ID value (12 bits) right justified in bits 20-31 (and preceding bits must be set to 0) • ATM VPI/VCI labels are encoded per [RFC3036] Section 3.4.2.2. • Frame-Relay DLCI label values are encoded per [RFC3036] Section 3.4.2.3. • Note: Bi-directional L2 LSPs are indicated by the presence of an upstream label in the Path message

5. Scope • Strictly limited to establishment and management of point-to-point LSPs across a layer two network/terminating hosts router router L2SC L2 LSP Not multi-access/exit bridge bridge L2SC L2 LSP

6. Discussions • Q1: *if* flows are discriminated on a local basis, I-d assumes a behavior not defined by the IEEE (initial last CCAMP meeting question) R1: there are equivalent mechanisms defined outside the scope of the IEEE (… at the IETF for instance) • Q2: if you discriminate flows based on the VLAN_ID what is the number of flows you can maintain? R2: 4k per port • Q3: how is the forwarding then performed R3: not necessarily using bridging/MAC learning as the point-to-point path for the frames is known from the LSP establishment (it is thus the establishment of the LSP that determines external behaviour of the forwarding function) • Note: as in any standard there is no point in detailing the exact implementation of the switching/ forwarding/connection function -

7. Discussions • Q4: does it require VLAN swapping/switching ? • R4: not mandatory and (taking a minimalistic assumption of VLAN continuity) just mandate ensuring per-port (not per node or other instance) VLAN interpretation and thus constraining the LSP  equivalent to a continuity principle (this can be tackled by using the label set mechanism) • However, VLAN_ID may be translated when crossing a node using a similar table as the one written in Appendix A of <draft-ietf-pwe3-ethernet-encap-08.txt>

8. Proposal • VLAN ID label => replace by generic 32 bit flow label (C-Type 2) • Add dedicated appendix on potential use of this field • Open questions • Do we need specific TAG Protocol ID ? • More high level perspective need to open communication with Ethernet owning SDO ? Need to prepare material e.g. framework, requirement, etc.

9. Backup Slides

10. (Detailed) Change from last version • add VLAN label space applicability • add reference to LSP splicing (see [RFC3473]) • MTU field in TSPEC fixed size of 53 bytes for ATM LSPs • clarify the TLV inclusion rules: L2 SENDER_TSPEC object MUST include at least one (i.e. the Type 1 TLV) and MAY include more than one optional TLV (for which the Type is > 1) • as QoS type could previously encode non QoS related parameters => disambiguate as the type 1 was mixed with the generic definition • clarify that "service class" field allows having multiple tuple of values - and details will follow in next revision

11. Security Section • Security threats: • Possibility for the network to control the traffic injected by the client in the data plane (BPDU, Multicast, Broadcasts, etc.) or the control plane (RSVP-TE signaling) • All usual threats brought by IP control (and data plane) • Entry points induced by the possible coexistence of the two technologies (L2LSPs and usual Broadcast Ethernet mode). Current RSVP security mechanisms [RFC2207], [RFC3097] to be analyzed/evaluated in the context of L2 LSPs • Attacks on the data plane • insertion of non-authenticated data traffic • Denial of Service (DoS) attacks • traffic snooping

12. Security Section • L2 LSP signaling • prevent these attacks by offering filtering (like ACLs, etc.) • reduce data plane threats, as the number of network entry points to control is reduced since L2 LSP are a single entry point (head-end LSR) • mechanism MUST be provided at the network edges (on the head-end LSRs), to rate limit the amount of traffic that can transit into a L2 LSP. • Attacks on the Control Plane • potential initiation of the signaling by the client side => control of such activity MUST be provided so that it cannot be used to fail the network • rate limit RSVP client control plane traffic (mainly refresh interval), the number of TE- LSPs that can be signaled by a particular client, etc. • Security problems induced by the migration if both L2 LSPs and classical Ethernet are used on the same network

13. Next Steps • Is document reasonable basis for progressing this work item ? • Consensus to make this document a CCAMP WG I-d ?

14. Layer 2 LSP Signaling • LABEL_REQUEST object (C-Type 4) • Encoding Type (link/port): ATM, FR or ETH • Switching Type: L2SC • G_PID: Carried Payload • New L2 SENDER_TSPEC/FLOWSPEC object (C-Type = 6) • SENDER_TSPEC: carries the traffic parameters as requested by the sender: bandwidth and layer 2 traffic specification • FLOWSPEC: carries the reservation request as specified by the RSVP receiver: identical to the SENDER_TSPEC object • LABEL object (C-Type = 2) • 32-bit value that allows sending and receiving node performing the link local operations for the requested L2 LSP • label MUST be interpreted according to the requestor traffic parameters, i.e. a label does not allow knowing the detailed properties of the requested L2 LSP (i.e. labels are context sensitive)

15. Layer 2 SENDER_TSPEC/FLOWSPEC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (12)| C-Type (6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Granularity | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Switching granularity: ATM VC/VP, FR port/DLCI, ETH port/frame mode • TLV Type 1 (L2 QoS): include requested bandwidth encoding 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Class | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Jitter (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+