TOC 
Network Working GroupN. Bahadur
Internet-DraftK. Kompella
Intended status: Standards TrackJuniper Networks, Inc.
Expires: April 30, 2009October 27, 2008


Mechanism for performing LSP-Ping over RSVP protection paths
draft-nitinb-lsp-ping-rsvp-protection-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 30, 2009.

Abstract

This document describes methods for performing lsp ping over mpls rsvp-te protection paths, when the protection paths are not in use. Conventional LSP-Ping follows the same path as data traffic. In some cases, it might be useful to follow the data path of protection paths (detours and bypasses) to ensure that the those paths are fully functional. This document describes enhancements to LSP-Ping to perform ping over such paths.



Table of Contents

1.  Introduction
2.  Motivation
3.  Exercising the protection path
    3.1.  Transit node re-route indication
        3.1.1.  RSVP IPv4 LSP Target FEC Stack Sub-TLV
        3.1.2.  RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV
        3.1.3.  RSVP IPv6 LSP Target FEC Stack Sub-TLV
        3.1.4.  RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV
    3.2.  Transit node re-route error reporting
    3.3.  Transit node automatic forwarding along protected path
4.  Performing LSP Ping along a protection path
    4.1.  Ingress node procedure
    4.2.  Transit node procedure
    4.3.  Egress node procedure
    4.4.  P2MP Considerations
    4.5.  Re-routing echo requests via forwarding plane
    4.6.  Multiple protection path consideration
    4.7.  Traceroute along protection path
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

This document describes methods for performing lsp ping over MPLS RSVP-TE protection paths, when the protection paths are not in use. Convention LSP-ping [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) packets follow the same path as data traffic and thus it validates the LSP control and forwarding planes. For MPLS LSPs signaled using RSVP-TE [RFC3209] (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.), protection mechanisms have been defined in [RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) enable the re-direction of traffic onto backup LSP tunnels in the event of a failure. Under normal operation, no data traffic passes through the backup tunnels. So under normal conditions, there is no way of verifying that when a failure will happen, data will correctly take the backup tunnel and eventually reach the LSP end point. This document defines enhancements to the LSP-Ping to enable verification of end-to-end data path via the backup LSP tunnel when the backup LSP tunnel is not in use.



 TOC 

1.1.  Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Motivation

[RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) describes mechanisms for performing protection of RSVP-TE signaled MPLS tunnels. The protection can be a one-to-one backup (detour) or a facility backup method (bypass) that creates one or more bypass LSPs for protecting one or more LSPs. I either case, the signaling is done in the control plane and protection path is not used until there is a failure in the LSP path being protected.

LSP-Ping [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) allows one to ping and trace the path of a LSP. LSP-Ping can be used (without any new extensions) to ping and trace the path of RSVP-TE protection paths. Thus, one can monitor the health of protection paths. However, this monitoring of the protection paths is done in isolation and not in combination with the actual path(s) being protected. In other words, the protection path might be UP, but on failure of the protected path, data traffic might not make it to the protected LSP end-point. Some of the reasons for this are as described below:

  1. Point of local repair (PLR) does not currently forward the incoming LSP traffic onto the protection path
  2. Actual forwarding failure with the protection path
  3. Merge point (end of protection path) does not correctly merge the traffic back to the LSP path

Thus, it is essential to have a mechanism to validate that the LSP protection will actually work in case of a failure. This draft provides extensions to LSP-Ping to allow the PLR to re-route the lsp-ping packets via the protection path



 TOC 

3.  Exercising the protection path



 TOC 

3.1.  Transit node re-route indication

To re-route an incoming packet via a protection path at a transit node, we need to provide some indication to the transit node that it should forward the lsp-ping echo request along the protection path. This is done by adding a flag field in the Target FEC Stack sub-TLV objects [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) for RSVP FECs.



 TOC 

3.1.1.  RSVP IPv4 LSP Target FEC Stack Sub-TLV



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 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 RSVP IPv4 LSP Target FEC Stack Sub-TLV 

RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).



 TOC 

3.1.2.  RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV



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 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           P2MP ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV 

RSVP P2MP IPv4 Session is a sub-TLV of Target FEC Stack TLV, defined in [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.). The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).



 TOC 

3.1.3.  RSVP IPv6 LSP Target FEC Stack Sub-TLV



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 tunnel end point address                 |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|          Tunnel ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv6 tunnel sender address                  |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 RSVP IPv6 LSP Target FEC Stack Sub-TLV 

RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).



 TOC 

3.1.4.  RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           P2MP ID                             |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero       |P|          Tunnel ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv6 tunnel sender address                  |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV 

RSVP P2MP IPv6 Session is a sub-TLV of Target FEC Stack TLV, defined in [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.).The P-bit has been added to indicate that the echo-request MUST be forwarded along a protection-path, if one is available. If a node does not understand the P-bit, it MUST return an error code of either" Malformed echo request received" or "One or more of the TLVs was not understood" [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). If no protection-path is available, then the node MUST return the error code defined in Section 3.2 (Transit node re-route error reporting).



 TOC 

3.2.  Transit node re-route error reporting

If a transit-node receives a echo request with an indication that the request needs to traverse a protection path, but no protection path is available, then the transit node should respond back with a new return code as defined below:

          Value    Meaning
          -----    -------
           TBD     Protection path not available

The Return Subcode for this Return Code MUST be set to zero and MUST be ignored.



 TOC 

3.3.  Transit node automatic forwarding along protected path

LSP-Ping [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) mandates that the destination IP of the lsp-ping echo request MUST be from the 127/8 range. This document proposes the use of address 127.255.255.255/32 to reflect that the packet be forwarded along a protection path. Details of the procedure are described in Section 4.5 (Re-routing echo requests via forwarding plane).



 TOC 

4.  Performing LSP Ping along a protection path



 TOC 

4.1.  Ingress node procedure

The RRO object sent upstream during the signaling of a MPLS RSVP-TE LSP contains information regarding protection availability on the downstream node. More specifically, [RFC4090] (Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” May 2005.) specifies bits in the RSVP record-route object (RRO), which specify if a transit node provides protection and if it provides node protection. Given this, the ingress node of a RSVP-TE LSP knows the state of protection along all hops of a LSP. Using this information, the ingress MAY choose to perform LSP pings only via nodes where protection is available. Attempting to perform lsp-ping via nodes where no protection is available will not cause harm, except for additional OAM load in the nodes.



 TOC 

4.2.  Transit node procedure



Ingress                                       Egress
   A           B          C           D           E
    o -------- o -------- o --------- o --------- o
                          |                      |
                           \____________________/
                                   Bypass


 Figure 1: Protected RSVP path 

In the above figure node C provides node protection. To perform a lsp-ping along the protection path originating at node C, ingress A MUST send a lsp-ping echo request message with TTL=2 and with the P-bit set in the RSVP FEC stack sub-TLV, see Section 3.1 (Transit node re-route indication). Due to TTL=2, the echo request will expire at node C. The transit node C on receipt of such a request SHOULD perform one of the following:

  1. If C does not understand the P-bit, C MAY respond back to A with an error.
  2. If C ignores the P-bit, then C MAY respond back to A with a return code indicating that it is a transit node
  3. If C understands the P-bit, then C SHOULD forward the lsp-ping echo request along the bypass path.

When the lsp-ping echo request is forwarded along the protection path, the following rules MUST be followed:

Node C MUST NOT forward the lsp-ping echo request along the regular (non-protection) LSP path.



 TOC 

4.3.  Egress node procedure

When the echo request reaches the egress, the egress will either identify it as a malformed packet (if it does not understand the P-bit and enforces the Must-be-zero) or the egress will process the packet as a regular lsp-ping echo request and respond back with an appropriate return code.

In either case, a response from the egress indicates that the packet indeed made it via the forwarding plane of the LSP's protection path. An error message from the egress does not necessarily mean that the packet was correctly forwarded to the egress. It only means that the packet made it to the egress.



 TOC 

4.4.  P2MP Considerations

[RFC4875] (Aggarwal, R., Papadimitriou, D., and S. Yasukawa, “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs),” May 2007.) specifies P2MP extenions for RSVP-TE and [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) specifies extensions to lsp-ping for P2MP.

The procedures outlined above are sufficient for P2MP. Using an appropriate MPLS TTL value (in the echo request) and P2MP Responder Identifier TLV ( [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) ), an ingress should be able to direct an echo request along a particular protection path to a particular egress. A protection path in P2MP may be protecting multiple egresses and for scalability considerations, one should regulate the number of lsp-pings exercising the same protection path.



 TOC 

4.5.  Re-routing echo requests via forwarding plane

The above mechanisms described for re-routing the echo requests on transit nodes onto a protection path may involve processing the lsp-ping echo request in the slow (non-forwarding) path. This document proposes the use of 127.255.255.255/32 IP destination address in the lsp-ping echo request to indicate that the packet should be forwarded along a protection path, if one exists. Thus, a transit node forwards packets along a protection path if and only if the destination IP address is 127.255.255.255/32 and the MPLS-TTL=1

The above technique is NOT mandatory and in the absence of the above, the packet will get processed by the slow-path on node C.



 TOC 

4.6.  Multiple protection path consideration

A transit node MAY have multiple paths protecting a downstream link or node. In such a case, which path the transit node chooses to forward the packets is a dependent on the transit node. This document does not make any requirements on the transit node to forward packets along a specific path or provide information along which path the packet was forwarded. In general, the transit node behavior for lsp-ping echo request messaegs should mimic the behavior for data packets in case there is a failure in the LSP path.



 TOC 

4.7.  Traceroute along protection path

At this time, it is not deemed necessary to provide any extensions to support traceroute (starting at LSP ingress) that traverses the protection path. Traceroute is a tool often used during network trouble-shooting. During trouble-shooting, one could use lsp-ping (with extensions specified in this draft) to detect/validate a failure with the path. Once a failure has been detected, one could use traceroute on the main LSP path and a traceroute on the protection path to isolate the issue. Proxy lsp-ping [I‑D.ietf‑mpls‑remote‑lsp‑ping] (Swallow, G. and V. Lim, “Proxy LSP Ping,” November 2008.) could be used to automate the network-troubleshooting by performing both the procedures from the LSP ingress itself.



 TOC 

5.  Security Considerations

The draft does not introduce any new security considerations. Those discussed in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) are also applicable to this document.

Tracing inside a bypass tunnel can be prevented by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel).



 TOC 

6.  IANA Considerations

A new Return Code is defined in Section 3.2 (Transit node re-route error reporting). IANA is requested to assign a new Return Code value for the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, "Return Codes" sub-registry as follows using a Standards Action value.

          Value    Meaning
          -----    -------
           TBD     Protection path not available



 TOC 

7.  Acknowledgements

The authors would like to thank Kenji Kumaki and Vach Kompella for their suggestions on the draft.



 TOC 

8.  References



 TOC 

8.1. Normative References

[I-D.ietf-mpls-p2mp-lsp-ping] Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” draft-ietf-mpls-p2mp-lsp-ping-10 (work in progress), March 2010 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4379] Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” RFC 4379, February 2006 (TXT).


 TOC 

8.2. Informative References

[I-D.ietf-mpls-remote-lsp-ping] Swallow, G. and V. Lim, “Proxy LSP Ping,” draft-ietf-mpls-remote-lsp-ping-03 (work in progress), November 2008 (TXT).
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” RFC 3209, December 2001 (TXT).
[RFC4090] Pan, P., Swallow, G., and A. Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” RFC 4090, May 2005 (TXT).
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs),” RFC 4875, May 2007 (TXT).


 TOC 

Authors' Addresses

  Nitin Bahadur
  Juniper Networks, Inc.
  1194 N. Mathilda Avenue
  Sunnyvale, CA 94089
  US
Phone:  +1 408 745 2000
Email:  nitinb@juniper.net
URI:  www.juniper.net
  
  Kireeti Kompella
  Juniper Networks, Inc.
  1194 N. Mathilda Avenue
  Sunnyvale, CA 94089
  US
Phone:  +1 408 745 2000
Email:  kireeti@juniper.net
URI:  www.juniper.net


 TOC 

Full Copyright Statement

Intellectual Property