Generalized MPLS RSVP-TE Signaling for Layer-2 LSPs D.Papadimitriou D.Brungard A.Ayyangar M.Vigoureux

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)

Step-by-step RFC3945 defines L2SC interface and support for L2SC LSP (RFC 3471/73 code-points) –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

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 (and preceding bits must be set to 0) ATM VPI/VCI labels are encoded per [RFC3036] Section Frame-Relay DLCI label values are encoded per [RFC3036] Section Note: Bi-directional L2 LSPs are indicated by the presence of an upstream label in the Path message

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

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 -

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

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.

Backup Slides

(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

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

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

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

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)

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