[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MPLS draft-chang-mpls-rsvpte-path-protection-ext-01.txt




Subject: MPLS draft-chang-mpls-rsvpte-path-protection-ext-
01.txt                        

NAME OF I-D: 
 
http://www.ietf.org/internet-drafts/draft-chang-mpls-rsvpte-path-
protection-ext-01.txt

SUMMARY 
 
To deliver reliable service, multi-protocol label switching (MPLS) requires a set of procedures to enable -
protection of the traffic carried on - label switched paths (LSPs). Thus existing signaling  mechanisms must 
be extended appropriately to support such  functionality.  Recently, RSVP-TE has introduced extensions to 
RSVP to support the establishment of LSP tunnels. This draft extends RSVP-TE to support path protection 
in MPLS. Specifically, we  provide signaling support for establishing backup LSPs and for propagating 
fault notification upon LSP failure.   
 
RELATED DOCUMENTS 

1.	Framework for MPLS-based Recovery, draft-ietf-mpls-recovery-frmwrk-02.txt
2.	Requirements for Traffic Engineering Over MPLS, RFC 2702
3.	Shared Backup Label Switched Path Restoration, draft-kini-restoration-shared-backup-00.txt
4.	RSVP Label Allocation for Backup Tunnels, draft-swallow-rsvp-bypass-label-01.txt
5.	Reservation Protocol with Traffic Engineering Extensions: Extension for Label Switched Path 
Restoration, draft-kini-rsvp-lsp-restoration-00.txt
6.	A Method for Setting an Alternative Label Switched Path to Handle Fast Reroute, draft-haskin-
mpls-fast-reroute-05.txt
7.	A Path Protection/Restoration Mechanism for MPLS Networks, draft-chang-mpls-path-protection-
02.txt
8.	Extensions to CRLDP for MPLS Path Protection, draft-owens-crldp-path-protection-ext-00.txt
9.	Generalized Multi-Protocol Label Switching (GMPLS) Architecture, draft-many-gmpls-
architecture-00.txt
10.	Enhanced LSP Services, draft-papadimitriou-enhanced-lsps-03.txt
11.	Generalized MPLS Recovery Mechanisms, draft-lang-ccamp-recovery-00.txt
12.	Open Shortest Path First (OSPF) protocol extensions for Label Switched Path restoration, draft-
kini-ospf-lsp-restoration-00.txt
13.	ReSerVation Protocol with Traffic Engineering extensions. Extension for Label Switched Path 
restoration, draft-kini-rsvp-lsp-restoration-00.txt

WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 
 
  Applications         +-------+  +-------+        (new) Hour glass 
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           / 
                   \   +-------+  +-------+               / 
                    \     +----------------------+       / 
                     \    |         CCAMP        |      / 
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext 
                     /    | control   | measure  |     \  
                    /     +----------------------+      \ 
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \ 
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\ 
                     +----+ +----+ +----+ +----+ +----+ 

This work is targeted for MPLS and should provide feedback to RSVP WG or future extensions.
 
WHY IS IT TARGETED AT THIS WG 
 
The following text is taken from the MPLS Charter goals:
"6. Specify MPLS-specific recovery mechanisms to allow one label-switched path to be used as backup for 
a set of other label-switched paths, including cases which permit local repair. What constitutes the 
necessary set of MPLS-specific recovery mechanism should be ascertained through cooperation with the 
CCAMP and TE working groups."

This draft, in conjunction with draft-chang-mpls-path-protection-02.txt, addresses MPLS WG's Charter 
Goal 6 since it specifies extensions to RSVP to support path-based restoration in MPLS networks. 
 
JUSTIFICATION 
 
The justification for this document is simple, the MPLS Charter goals are to address MPLS specific 
restoration and that is exactly what this RSVP extension draft provides. This is not a new work item, it has 
been worked on for the last year on the WG mailing list and discussed at IETF meetings. Once the approval 
is given to progress this draft, it will go for WG consensus, WG last call, and then progress for 
Informational RFC.