IETF 96 (MPLS WG) Abhishek Deshmukh Kireeti Kompella (presenting)

Slides:



Advertisements
Similar presentations
MPLS Multiple Topology Support draft-zhao-mpls-ldp-multiple-topology-01 draft-zhao-mpls-rsvp-te-multiple-topology-01 IETF 80 – Prague.
Advertisements

OLD DOG CONSULTING Challenges and Solutions for OAM in Point-to-Multipoint MPLS Adrian Farrel, Old Dog Consulting Ltd. Zafar Ali, Cisco Systems, Inc.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-1 MPLS TE Overview Understanding MPLS TE Components.
Pseudowire Endpoint Fast Failure Protection draft-shen-pwe3-endpoint-fast-protection-00 Rahul Aggarwal Yimin Shen
MPLS additions to RSVP Tunnel identification Tunnel parameter negotiation Routing policy distribution Routing debugging information Scalability improvements.
Copyright: RSVP The ReSerVation Protocol by Sujay koduri.
CS Summer 2003 Lecture 12 FastReRoute (FRR) - Big Picture.
CS Summer 2003 Lecture 9. CS Summer 2003 FILTERSPEC Object FILTERSPEC Object defines filters for selecting a subset of data packets in a session.
draft-kompella-mpls-rmr Kireeti Kompella IETF 91
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 (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
CS 268: Integrated Services Lakshminarayanan Subramanian Feb 20, 2003.
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,
IETF 66 L1VPN Basic Mode Draft draft-ietf-l1vpn-basic-mode-00.txt Don Fedyk (Editor) Yakov Rekhter (Editor)
1 © 1999, Cisco Systems, Inc _05F9-c1 Aggregated RSVP Bruce, Carol, Francois, and Fred Taggers on the Information Superhighway.
Kireeti Kompella draft-kompella-mpls-rmr-01
IP Traffic Engineering RSP draft-shen-ip-te-rsp-01.txt Naiming Shen Albert Tian Jun Zhuang
QoS in Mobile IP by Preethi Tiwari Chaitanya Deshpande.
ReSerVation Protocol (RSVP) Presented by Sundar P Subramani UMBC.
Draft-li-mpls-proxy-te-lsp-01IETF 90 MPLS1 Proxy MPLS Traffic Engineering Label Switched Path(LSP) draft-li-mpls-proxy-te-lsp-01 Zhenbin Li, Xinzong Zeng.
Draft-li-mpls-proxy-te-lsp-00IETF 87 MPLS1 Proxy MPLS Traffic Engineering Label Switched Path(LSP) draft-li-mpls-proxy-te-lsp-00 Zhenbin Li, Xinzong Zeng.
Label Distribution Protocols LDP: hop-by-hop routing RSVP-TE: explicit routing CR-LDP: another explicit routing protocol, no longer under development.
Generic Aggregation of Resource Reservation Protocol (RSVP) for IPv4 and IPv6 Reservation over PCN domains Georgios Karagiannis, Anurag Bhargava draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.
Establishing P2MP MPLS TE LSPs draft-raggarwa-mpls-p2mp-te-02.txt Rahul Aggarwal Juniper Networks.
RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-00 Yimin Shen (Juniper Networks) Yuji Kamite (NTT Communication) IETF 83, Paris, France.
Support for RSVP-TE in L3VPNs Support for RSVP-TE in L3VPNs draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01.txt Kenji Kumaki KDDI Corporation Tomoki Murai Furukawa.
Extensions to RSVP-TE for LSP Ingress Local Protection draft-ietf-teas-rsvp-ingress-protection-04 Huaimo Chen, Raveendra Torvi Autumn Liu, Tarek Saad,
IETF 67, Nov 2006Slide 1 VCCV Extensions for Multi- Segment Pseudo-Wire draft-hart-pwe3-segmented-pw-vccv-01.txt draft-ietf-pwe3-segmented-pw-04.txt Mustapha.
RSVP-TE Extensions to Realize Dynamic Binding of Associated Bidirectional LSP CCAMP/MPLS WG, IETF 79th, Beijing, China draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-01.
Analysis on Two Methods in Ingress Local Protection.
60th IETF San Diego August 2004 TE parameters to be exchanged between GMPLS-controlled ASes draft-otani-ccamp-interas-gmpls-te-00.txt Tomohiro Otani
RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-03
BGP extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN draft-kumaki-pce-bgp-disco-attribute-03.txt Kenji Kumaki KDDI R&D Labs,
Residence Time Measurement draft-mirsky-mpls-residence-time-02
Zhenbin Li, Li Zhang(Huawei Technologies)
Inter domain signaling protocol
Lecture 11: LDP, RSVP, RSVP-TE.
P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels
MPLS LSP Instant Install draft-saad-mpls-lsp-instant-install-00
RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-02
EE 122: Lecture 16/17 (Integrated Services)
Francois Le Faucheur Cisco
draft-ietf-mpls-rmr Kireeti Kompella & Luis Contreras
PLR Designation in RSVP-TE FRR
Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs draft-ietf-teas-gmpls-lsp-fastreroute-06 Authors: Mike Taillon.
LDP Extensions for RMR draft-esale-mpls-ldp-rmr- extensions
Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt Zafar Ali, Cisco Systems.
Fast Reroute for Node Protection in LDP- based LSPs
CHAPTER 8 Network Management
Greg Mirsky Jeff Tantsura Mach Chen Ilya Varlashkin
NSIS Operation Over IP Tunnels draft-shen-nsis-tunnel-01.txt
draft-sitaraman-mpls-rsvp-shared-labels-00
IETF 98 (MPLS WG) Abhishek Deshmukh (presenting) Kireeti Kompella
LSP Fast-Reroute Using RSVP Detours
NSIS Operation Over IP Tunnels draft-ietf-nsis-tunnel-04.txt
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.
Technical Issues with draft-ietf-mpls-bfd-directed
Advanced Computer Networks
Fast Reroute for Node Protection in LDP- based LSPs
Anup K.Talukdar B.R.Badrinath Arup Acharya
Extensions to G/RSVP-TE for Point to Multipoint TE LSPs R.Aggarwal, D.Papadimitriou, and S.Yasukawa (Editors)
IETF 102 (TEAS WG) Abhishek Deshmukh (presenting) Kireeti Kompella
draft-ietf-mpls-rmr IETF 99 (Prague)
WG Document Status Compiled By: Matt Hartley, Lou Berger, Vishnu Pavan Beeram IETF TEAS Working Group.
YANG Data Models for TE and RSVP draft-ietf-teas-yang-te-19 draft-ietf-teas-yang-rsvp-10 draft-ietf-teas-yang-rsvp-te-05 draft-ietf-teas-yang-te-mpls-01.
IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels Tarek Saad, Juniper Networks Vishnu Pavan Beeram, Juniper.
draft-kompella-spring-rmr
Jia He Italo Busi Jeong-dong Ryoo Bin Yeong Yoon Peter Park
WG Document Status Compiled By: Matt Hartley, Lou Berger, Vishnu Pavan Beeram IETF TEAS Working Group.
Zhaohui (Jeffrey) Zhang
Presentation transcript:

IETF 96 (MPLS WG) Abhishek Deshmukh Kireeti Kompella (presenting) RSVP Protocol extensions for Resilient MPLS Rings draft-deshmukh-rsvp-rmr-extension-00 IETF 96 (MPLS WG) Abhishek Deshmukh Kireeti Kompella (presenting)

Introduction draft-deshmukh-rsvp-rmr-extension-00 describes the RSVP extensions needed to support RMR RMR LSPs have a few differences with “regular” unicast RSVP-TE LSPs

Differences Ring LSPs (by construction) form a loop A Ring LSP is multipoint to point (MP2P) Each RMR LSP has one egress node but can have multiple ingress nodes The bandwidth of a ring LSP can change hop-to-hop (since it is MP2P) Ring LSP protection is akin to SONET/SDH ring protection

Extensions - Session Object RMR_TUNNEL_IPv4 Session Object Class = SESSION, RMR_TUNNEL_IPv4 C-Type = TBD 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring anchor node address | | Ring Flags | MBB ID | | Ring ID | Ring anchor node address IPv4 address of the anchor node. Each anchor node creates a LSP addressed to itself Ring Flags 1 = Clockwise 2 = Anti-Clockwise MBB ID A 16-bit identifier used in the SESSION. This "Make- before-break" (MBB) ID is useful for graceful ring changes. Ring ID A 32-bit identifier for the ring.

Extensions - Sender Template Object Sender Template & Filter Spec Object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring tunnel sender address | | Must be zero | LSP ID | Ring tunnel sender address IPv4 loopback address of the sender . LSP ID A 16-bit identifier used in the SENDER_TEMPLATE. No changes to the format of SENDER_TEMPLATE and FILTER_SPEC objects. Only the semantics of these objects will slightly change. Different sender template & filter spec objects can be inserted by different nodes along the ring which can be used for RMR bandwidth management.

Ring LSPs: Bandwidth Management Let’s say that the CW & AC anchor LSPs are already established for node 1 – LSP1. (Green arrow LSP) Let’s focus on the CW LSP. Now, node 5 wants to achieve BW increase from 0G to 1G (Blue arrow LSP) Similarly node 6 may want to increase BW (Purple arrow LSP) Now, let’s say, node 5 wants to increase bw again from 1G to 2G 17 10 17 1 17 2 17 9 17 8 17 3 17 7 17 4 17 6 17 5

Ring LSPs: Bandwidth Management Let’s say that the CW & AC anchor LSPs are already established for node 1 – LSP1. (Green arrow LSP) To increase the BW, node 5 will signal a new Path message with a different sender-template object for “LSP1” towards node 1. Ring tunnel sender address = node 5; lsp-id = 1 Node 1 will respond with Resv message for this new path if sufficient bw is available. This Resv message will have the appropriate filter-spec object. (Blue arrow LSP) Similarly node 6 can increase BW by signaling a new Path message with different sender template object with its own address. (Purple arrow LSP) If node 5 wants to increase bw again from 1G to 2G, then it will again create a new Path message for “lsp1” with Ring tunnel sender address = node 5 & lsp-id = 2 17 10 17 1 17 2 17 9 17 8 17 3 17 7 17 4 17 6 17 5

Ring LSPs: Bandwidth Management The goal is to achieve a smooth change of bandwidth without disrupting the existing LSP At the same time, if bandwidth is not available, the aim is to reject the update (again without disrupting the existing LSP) but targeted specifically to the requesting node

Ring LSPs: Bandwidth Management If sufficient BW is not available at some Downstream (say node 9), then ring node 9 will generate PathErr with the corresponding Sender Template Object. When ring node 5 no longer needs the bw reservation, then ring node 5 will originate a PathTear message with the corresponding Sender Template Object. Every downstream node will then remove bw allocated on the corresponding link. Note that we will not actually change any label as part of this bw increase. So, the label remains same as it is signaled initially for the anchor LSP. Only the BW accounting changes when these Path messages get signaled.

For Further Study Is an ERO needed for Ring LSPs? When a ring changes, how will Ring LSPs be maintained without disruption? What is the best way to use express links?