One document matched: draft-eriksson-ldp-convergence-term-03.txt
Differences from draft-eriksson-ldp-convergence-term-02.txt
Network Working Group T. Eriksson
Internet Draft TeliaSonera
Expires: December 2006 S. Poretsky
Reef Point
R. Papneja
Isocore
J. Karthik
Cisco Systems
June 26, 2006
Terminology for Benchmarking LDP Data Plane Convergence
<draft-eriksson-ldp-convergence-term-03.txt>
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.
This document may only be posted in an Internet-Draft.
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
Vapiwala, Karthik,Papneja Expires December 26, 2006 [Page 1]
Poretsky, Rao, Le Roux
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
Abstract
This document defines new terms for benchmarking of LDP convergence.
These terms are to be used in future methodology documents for
benchmarking LDP Convergence. Existing BMWG terminology documents such
as IGP Convergence Benchmarking [3] provide useful terms for LDP
Convergence benchmarking. These terms are discussed in this document.
Applicable terminology for MPLS and LDP defined in MPLS WG RFCs [1] and
[2] is also discussed.
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 RFC 2119 [RFC2119].
Table of Contents
1. Introduction...................................................2
2. Existing definitions...........................................3
3. Term Definitions...............................................5
4. Security Considerations.......................................12
5. Acknowledgements..............................................13
6. References....................................................13
7. Author's Address..............................................13
1. Introduction
This draft describes the terminology for benchmarking LDP Convergence.
An accompanying document describes the methodology for doing the
benchmarking [TBD]. The main motivation for doing this work is the
increased focus on lowering convergence time for LDP as an alternative
to other solutions such as MPLS Fast Reroute (i.e. protection techniques
using RSVP-TE extensions).
The purpose of this documents is to find existing terminology as well
as define new terminology when needed terms are not available. The
terminology will support the methodology that will be based on black-box
testing of the LDP dataplane. The approach is very similar to the one
found in [3] and [4].
Eriksson, et al Expires December 26, 2006 [Page 2]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
2. Existing definitions
2.1 BMWG Convergence Terms
Route Convergence
Defined in [3].
Convergence Packet Loss
Defined in [3].
Convergence Event Instant
Defined in [3].
Convergence Recovery Instant
Defined in [3].
Rate-Derived Convergence Time
Defined in [3].
Convergence Event Transition
Defined in [3].
Convergence Recovery Transition
Defined in [3].
Loss-Derived Convergence Time
Defined in [3].
Restoration Convergence Time
Defined in [3].
Packet Sampling Interval
Defined in [3].
Local Interface
Defined in [3].
Neighbor Interface
Defined in [3].
Eriksson, et al Expires December 26, 2006 [Page 3]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
Remote Interface
Defined in [3].
Preferred Egress Interface
Defined in [3].
Next-Best Egress Interface
Defined in [3].
Stale Forwarding
Defined in [3].
2.2 MPLS/LDP Terms
Label
Defined in [1].
FEC
Defined in [1].
Label Withdraw
Defined in [2].
IGP update message
Typically an IS-IS LSP or an OSPF LSA that contains information
about a change in the IGP topology.
LSP
Defined in [1].
LSR
Defined in [1].
Per-Interface label space
Defined in [1]
Per-Platform label space
Defined in [1]
Eriksson, et al Expires December 26, 2006 [Page 4]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
MPLS Node
Defined in [1].
MPLS Edge Node
Defined in [1].
MPLS EgressNode
Defined in [1].
MPLS Ingress Node
Defined in [1].
Upstream LSR
Defined in [1].
Downstream LSR
Defined in [1].
3. Term Definitions
3.1 LDP Binding Table
Definition:
Table in which the LSR maintains all learned labels. It consists
of the prefix and label information bound to a peer's LDP
identifier and the list of sent and received bindings/peer.
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
FEC Forwarding Table
3.2 FEC Forwarding Table
Eriksson, et al Expires December 26, 2006 [Page 5]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
Definition:
Table in which the LSR maintains the next hop information for the
particular FEC with the associated outgoing label and interface.
The information used for setting up the FEC forwarding table is
retrieved from the LDP Binding Table.
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
LDP Binding Table
3.3 FEC Convergence Event
Definition:
The occurrence of a planned or unplanned action in the network
that results in a change to an LSR's LDP next-hop forwarding.
Discussion:
Convergence Events include link loss, routing protocol session
loss, router failure, and better next-hop. Also, different types
of administrative events such as interface shutdown is
considered.
Measurement Units:
N/A
Issues:
None
See Also:
FEC Forwarding Table Convergence
FEC Convergence
3.4 FEC Forwarding Table Convergence
Definition:
Recovery from a FEC Convergence Event that causes the FEC
Forwarding Table to change and re-stabilize.
Eriksson, et al Expires December 26, 2006 [Page 6]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
Discussion:
FEC Forwarding Table Convergence updates after the RIB and LDP
Binding Table update due to a FEC Convergence Event. FEC
Forwarding Table Convergence can be observed externally by the
rerouting of data Traffic to a new egress interface.
Measurement Units:
N/A
Issues:
None
See Also:
FEC Forwarding Table
FEC Convergence Event
FEC Convergence
3.5 FEC Convergence
Definition:
Recovery from a FEC Convergence Event that causes the LDP Binding
Table to change and re-stabilize.
Discussion:
FEC Convergence is a change in an LDP Binding of a prefix and
label to a peer's LDP Identifier. This change can be an update or
recovery due to a FEC Convergence Event. FEC Convergence is an
LSR action made prior to FEC Forwarding Table Convergence. FEC
Convergence is not an externally observable Black-Box measurement.
Measurement Units:
N/A
Issues:
Where is LDP Identifier defined? Where is LDP Binding defined?
See Also:
LDP Binding Table
FEC Convergence Event
FEC Forwarding Table Convergence
3.6 Multiple Next-Hop FEC
Definition:
Eriksson, et al Expires December 26, 2006 [Page 7]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
A FEC with more than one next-hop and associated outgoing label
and interface.
Discussion:
A Multiple Next-Hop FEC can be verified from the FEC Forwarding
Table and from externally observing traffic being forwarded to a
FEC on one or more interfaces.
Measurement Units:
N/A
Issues:
None
See Also:
FEC Forwarding Table
3.7 Ingress LSR
Definition:
An MPLS ingress node which is capable of forwarding native L3
packets.
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
MPLS Node
MPLS Edge Node
MPLS Egress Node
MPLS Ingress Node
Label Switching Router (LSR)
Egress LSR
3.8 Egress LSR
Definition:
An MPLS Egress node which is capable of forwarding native L3
packets.
Eriksson, et al Expires December 26, 2006 [Page 8]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
MPLS Node
MPLS Edge Node
MPLS Egress Node
MPLS Ingress Node
Label Switching Router (LSR)
Ingress LSR
3.9 LDP Peer
Definition:
An adjacent LSR with which LDP adjacency is established
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
Targeted LDP Peer
3.10 Targeted LDP Peer
Definition:
An adjacent LSR (usually more than a hop away) with which LDP
adjacency is established through a directed hello message which is
unicast.
Discussion:
Eriksson, et al Expires December 26, 2006 [Page 9]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
None
Measurement Units:
N/A
Issues:
None
See Also:
LDP Peer
3.11 Targeted FECs
Definition:
A FECs advertised by a Targeted LDP Peer
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
Targeted Peer
3.12 Multi-Labeled Packets
Definition:
A data packet that has more than one label in the label stack.
Discussion:
This typically happens when a Targeted Peer is established over a
traffic engineered tunnel.
Measurement Units:
N/A
3.13 Equal Cost Multiple Paths
Definition:
Existence of multiple IGP paths to reach a particular destination.
In this case the depending on the implementation traffic destined
Eriksson, et al Expires December 26, 2006 [Page 10]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
to a prefix that has multiple equal cost paths is load balanced
across all these paths.
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
Equal Cost Multiple FECs
3.14 Equal Cost Multiple FECs
Definition:
Existence multiple FECs to reach a destination. Typically the LSR
that has multiple FECs of equal costs does a load balance on all
the FECs
Discussion:
None
Measurement Units:
N/A
Issues:
None
See Also:
Equal Cost Multiple Paths
3.15 FEC Convergence at Ingress LSR
Definition:
Recovery from a FEC Convergence Event that causes the LDP Binding
Table to change and re-stabilize at the Ingress LSR
Discussion:
FEC Convergence is a change in an LDP Binding of a prefix and
label to a peer's LDP Identifier. This change can be an update or
Eriksson, et al Expires December 26, 2006 [Page 11]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
recovery due to a FEC Convergence Event. FEC Convergence is an
LSR action made prior to FEC Forwarding Table Convergence. FEC
Convergence is not an externally observable Black-Box measurement.
Measurement Units:
N/A
Issues:
Where is LDP Identifier defined? Where is LDP Binding defined?
See Also:
LDP Binding Table
FEC Convergence Event
FEC Forwarding Table Convergence
3.16 FEC Convergence at a midpoint LSR
Definition:
Recovery from a FEC Convergence Event that causes the LDP Binding
Table to change and re-stabilize at a midpoint LSR
Discussion:
FEC Convergence is a change in an LDP Binding of a prefix and
label to a peer's LDP Identifier. This change can be an update or
recovery due to a FEC Convergence Event. FEC Convergence is an
LSR action made prior to FEC Forwarding Table Convergence. FEC
Convergence is not an externally observable Black-Box measurement.
Measurement Units:
N/A
Issues:
Where is LDP Identifier defined? Where is LDP Binding defined?
See Also:
LDP Binding Table
FEC Convergence Event
FEC Forwarding Table Convergence
4. Security Considerations
Documents of this type do not directly affect the security of
Eriksson, et al Expires December 26, 2006 [Page 12]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
the Internet or of corporate networks as long as benchmarking
is not performed on devices or systems connected to operating
networks.
5. Acknowledgements
We thank Al Morton for providing valuble comments to this document.
6. References
[1] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[3] Poretsky, S.,"Terminology for Benchmarking IGP Data Plane Route
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-11 (work
in progress), May 2006.
[4] Poretsky, S. and B. Imhoff, "Benchmarking Methodology for IGP
Data Plane Route Convergence",
draft-ietf-bmwg-igp-dataplane-conv-meth-11 (work in progress),
May 2006.
7. Author's Address
Thomas Eriksson
TeliaSonera
Email: thomas.a.eriksson@teliasonera.com
Rajiv Papneja
Isocore
12359 Sunrise Valley Drive, STE 100
Reston, VA 20190
Eriksson, et al Expires December 26, 2006 [Page 13]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
USA
Phone: +1 703 860 9273
Email: rpapneja@isocore.com
Scott Poretsky
Reef Point Systems
8 New England Executive Park
Burlington, MA 01803
USA
Phone: + 1 781 395 5090
Email: sporetsky@reefpoint.com
Jay Karthik
Cisco System
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 936 0533
Email: jkarthik@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Eriksson, et al Expires December 26, 2006 [Page 14]
Internet-Draft Term for Benchmarking LDP Data Plane June 2006
Convergence
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eriksson, et al Expires December 26, 2006 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 13:32:36 |