rfc3035.txt

最新的RFC

RFC 3035          MPLS using LDP and ATM VC Switching       January 2001


11.2. When to Send Path Vectors Upstream

   As specified in section 8, there are circumstances in which an LSR R
   must inform its upstream neighbors, via a label binding response
   message, of a change in hop count for a particular LSP.  If the
   following conditions all hold:

      -  R is configured for the LDPV procedure,

      -  R supports VC-merge,

      -  R is not the egress for that LSP, and

      -  R is not informing its neighbors of a decrease in the hop
         count,

   then R MUST include a path vector object in the response message.

   If the change in hop count is a result of R's having been informed by
   its next hop, S, of a change in hop count, and the message from S to
   R included a path vector object, then if the above conditions hold, R
   MUST add itself to this object and pass the result upstream.
   Otherwise, if the above conditions hold, R MUST create a new object
   with only its own address.

   If R is configured for the LDPV procedure, and R supports VC merge,
   then it MAY include a path vector object in any label binding
   response message that it sends upstream.  In particular, at any time
   that R receives a label binding response from its next hop, if that
   response contains a path vector, R MAY (if configured for the LDPV
   procedure) send a response to its upstream neighbors, containing the
   path vector object formed by adding its own address to the received
   path vector.

   If R does not support VC merge, it SHOULD NOT send a path vector
   object upstream.

   If an LSR  receives a message from  its next hop, with a  path vector
   object containing its own address, then  LSR  MUST act as it would if
   it received a message with a hop count equal to MAXHOP.

   LSRs which are configured for the LDPV procedure SHOULD NOT store a
   path vector once the corresponding path vector object has been
   transmitted.







Davie                       Standards Track                    [Page 16]

RFC 3035          MPLS using LDP and ATM VC Switching       January 2001


   Note that if the ATM-LSR domain consists entirely of non-merging
   ATM-LSRs, path vectors need not ever be sent upstream, since any
   loops will be detected by means of the path vectors traveling
   downstream.

   By not sending path vectors unless the hop count increases, one
   avoids sending them in many situations when there is no loop.  The
   cost is that in some situations in which there is a loop, the time to
   detect the loop may be lengthened.

12. Security Considerations

   The encapsulation and procedures specified in this document do not
   interfere in any way with the application of authentication and/or
   encryption to network layer packets (such as the application of IPSEC
   to IP datagrams).

   The procedures described in this document do not protect against the
   alteration (either accidental or malicious) of MPLS labels.  Such
   alteration could cause misforwarding.

   The procedures described in this document do not enable a receiving
   LSR to authenticate the transmitting LSR.

   A discussion of the security considerations applicable to the label
   distribution mechanism can be found in [2].

13. Intellectual Property Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.




Davie                       Standards Track                    [Page 17]

RFC 3035          MPLS using LDP and ATM VC Switching       January 2001


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

14. References

   [1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label
       Switching Architecture", RFC 3031, January 2001.

   [2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas,
       "LDP Specification", RFC 3036, January 2001.

   [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
       Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
       January 2001.

   [4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification
       over ATM Link for LDP", RFC 3038, January 2001.

   [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM
       Adaptation Layer 5", RFC 2684, September 1999.

15. Acknowledgments

   Significant contributions to this work have been made by Anthony
   Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
   Littlewood and Dan Tappan.  We thank Alex Conta for his comments.

16. Authors' Addresses

   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Paul Doolan
   Ennovate Networks Inc.
   60 Codman Hill Rd
   Boxborough, MA 01719

   EMail: [e-mail]





Davie                       Standards Track                    [Page 18]

RFC 3035          MPLS using LDP and ATM VC Switching       January 2001


   Jeremy Lawrence
   Cisco Systems, Inc.
   99 Walker St.
   North Sydney, NSW, Australia

   EMail: [e-mail]


   Keith McCloghrie
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   EMail: [e-mail]


   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089

   EMail: [e-mail]


   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]













Davie                       Standards Track                    [Page 19]

RFC 3035          MPLS using LDP and ATM VC Switching       January 2001


17.  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Davie                       Standards Track                    [Page 20]