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

Slides:



Advertisements
Similar presentations
CCAMP WG, IETF 80th, Prague, Czech Republic draft-gonzalezdedios-subwavelength-framework-00 Framework for GMPLS and path computation support of sub-wavelength.
Advertisements

Identifying MPLS Applications
OLD DOG CONSULTING Challenges and Solutions for OAM in Point-to-Multipoint MPLS Adrian Farrel, Old Dog Consulting Ltd. Zafar Ali, Cisco Systems, Inc.
CPSC Network Layer4-1 IP addresses: how to get one? Q: How does a host get IP address? r hard-coded by system admin in a file m Windows: control-panel->network->configuration-
Computer Networks20-1 Chapter 20. Network Layer: Internet Protocol 20.1 Internetworking 20.2 IPv IPv6.
Network Layer IPv6 Slides were original prepared by Dr. Tatsuya Suda.
IP over ETH over IEEE draft-riegel-16ng-ip-over-eth-over Max Riegel
Packet Switching COM1337/3501 Textbook: Computer Networks: A Systems Approach, L. Peterson, B. Davie, Morgan Kaufmann Chapter 3.
Requirement and protocol for WSON and non-WSON interoperability CCAMP WG, IETF 81th, Quebec City, Canada draft-shimazaki-ccamp-wson-interoperability-00.
CCAMP - 69th IETF1 Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) draft-berger-ccamp-gmpls-mef-uni-00.txt.
Copyright: RSVP The ReSerVation Protocol by Sujay koduri.
CS Summer 2003 Lecture 6. CS Summer 2003 Hierarchical LSP LSP1 LSP2 LSP3 Ingress LSR for LSP1 Egress LSR for LSP1 Ingress LSR for LSP3 Hierarchical.
MPLS H/W update Brief description of the lab What it is? Why do we need it? Mechanisms and Protocols.
CS Summer 2003 Lecture 8. CS Summer 2003 Populating LFIB with LDP Assigned/Learned Labels Changes in the LFIB may be triggered routing or.
MPLS A single forwarding paradigm (label swapping), multiple routing paradigms Multiple link-specific realizations of the label swapping forwarding paradigm.
CS Summer 2003 Lecture 9. CS Summer 2003 FILTERSPEC Object FILTERSPEC Object defines filters for selecting a subset of data packets in a session.
Multi-Protocol Label Switching
A Study of MPLS Department of Computing Science & Engineering DE MONTFORT UNIVERSITY, LEICESTER, U.K. By PARMINDER SINGH KANG
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-1 Frame-Mode MPLS Implementation on Cisco IOS Platforms Configuring Frame-Mode MPLS on Cisco.
1 Multi-Protocol Label Switching (MPLS) presented by: chitralekha tamrakar (B.S.E.) divya krit tamrakar (B.S.E.) Rashmi shrivastava(B.S.E.) prakriti.
Ethernet TSPEC and MEF Parameters draft-ietf-mef-ethernet-traffic-parameters-01.txt
IETF68 CCAMP1 GMPLS Control of Ethernet Forwarding Don Fedyk Loa Andersson
Network Redundancy Multiple paths may exist between systems. Redundancy is not a requirement of a packet switching network. Redundancy was part of the.
1 Fabio Mustacchio - IPS-MOME 2005 – Warsaw, March 15th 2005 Overview of RSVP-TE Network Simulator: Design and Implementation D.Adami, C.Callegari, S.Giordano,
1 Multi Protocol Label Switching Presented by: Petros Ioannou Dept. of Electrical and Computer Engineering, UCY.
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
Network Components: Assignment Three
1 Multiprotocol Label Switching. 2 “ ” It was designed to provide a unified data-carrying service for both circuit-based clients and packet-switching.
End-to-end resource management in DiffServ Networks –DiffServ focuses on singal domain –Users want end-to-end services –No consensus at this time –Two.
IP QoS for 3G. A Possible Solution The main focus of this network QoS mechanism is to provide one, real time, service in addition to the normal best effort.
IP/MPLS Multiprotocol Label Switching
– Chapter 5 – Secure LAN Switching
Network Security1 – Chapter 5 – Secure LAN Switching Layer 2 security –Port security –IP permit lists –Protocol filtering –Controlling LAN floods (using.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS Introduction Module 4: Frame Mode MPLS Implementation.
MEF Ethernet Traffic Parameters draft-dimitri-mef-ethernet-traffic-parameters-00.txt IETF65 - Dallas - Mar’06.
MPLS Forwarder Preliminary 1 Outline MPLS Overview MPLS Overview MPLS MRD MPLS Data Path HLD 48K MPLS Fwder HLD IPE MPLS Fwder HLD Issues Summary.
Draft-shiomoto-ccamp-switch-programming-00 74th IETF San Francisco March Advice on When It is Safe to Start Sending Data on Label Switched Paths.
CSC 600 Internetworking with TCP/IP Unit 7: IPv6 (ch. 33) Dr. Cheer-Sun Yang Spring 2001.
GMPLS-controlled Ethernet Label Switching (GELS) BOF IETF 64 - Vancouver - Nov’05.
1 © 2003, Cisco Systems, Inc. All rights reserved. CCNA 3 v3.0 Module 9 Virtual Trunking Protocol.
Extensions to G/RSVP-TE for Point to Multipoint TE LSPs R.Aggarwal, D.Papadimitriou, and S.Yasukawa (Editors) and contributors (L.Berger, I.Bryskin, D.Cheng,
Framework for G.709 Optical Transport Network (OTN) draft-ietf-ccamp-gmpls-g709-framework-05 CCAMP WG, IETF 82 nd Taipei.
MULTI-PROTOCOL LABEL SWITCHING Brandon Wagner. Lecture Outline  Precursor to MPLS  MPLS Definitions  The Forwarding Process  MPLS VPN  MPLS Traffic.
DetNet Data Plane using PseudoWires Jouni Korhonen Shahram Davari Norm Finn IETF#94, Yokohama.
June 4, 2003Carleton University & EIONGMPLS - 1 GMPLS Generalized Multiprotocol Label Switching Vijay Mahendran Sumita Ponnuchamy Christy Gnanapragasam.
Optical + Ethernet: Converging the Transport Network An Overview.
Multiple Protocol Support: Multiprotocol Level Switching.
1 Header Compression over IPsec (HCoIPsec) Emre Ertekin, Christos Christou, Rohan Jasani {
55th IETF GSMP WG, Atlanta 1 General Switch Management Protocol (GSMP) v3 for Optical Support 55 th IETF GSMP WG, Atlanta Jun Kyun Choi
1 68th IETF, Prague, March 2007 Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-04.txt.
Multi layer implications in GMPLS controlled networks draft-bcg-ccamp-gmpls-ml-implications-05 D.Papadimitriou (Alcatel-Lucent) D.Ceccarelli (Ericsson)
OSPF Traffic Engineering (TE) Express Path Updates draft-giacalone-ospf-te-express-path-01.txt Spencer Giacalone, Alia Atlas, John Drake, Stefano Previdi,
Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 1 MPLS Upstream Label Assignment for RSVP- TE and LDP draft-raggarwa-mpls-rsvp-ldp-upstream-
K. Salah1 Security Protocols in the Internet IPSec.
Establishing P2MP MPLS TE LSPs draft-raggarwa-mpls-p2mp-te-02.txt Rahul Aggarwal Juniper Networks.
Multi-protocol Label Switching
MPLS Introduction How MPLS Works ?? MPLS - The Motivation MPLS Application MPLS Advantages Conclusion.
Multiprotocol Label Switching (MPLS) Routing algorithms provide support for performance goals – Distributed and dynamic React to congestion Load balance.
Multi-protocol Label Switching (MPLS) RFC 3031 MPLS provides new capabilities: QoS support Traffic engineering VPN Multiprotocol support.
Residence Time Measurement draft-mirsky-mpls-residence-time-02
MPLS LSP Instant Install draft-saad-mpls-lsp-instant-install-00
Chapter 4 Data Link Layer Switching
VLAN Trunking Protocol
Routing and Switching Essentials v6.0
CHAPTER 8 Network Management
draft-ggalimbe-ccamp-flexigrid-carrier-label-02
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
Editors: Bala’zs Varga, Jouni Korhonen
TRILL Header Extension Improvements
Presentation transcript:

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) |