draft-ietf-bmwg-protection-meth-05.txt   draft-ietf-bmwg-protection-meth-06.txt 
Network Working Group R. Papneja Network Working Group R. Papneja
Internet Draft Isocore Internet Draft Isocore
Intended Status: Informational Intended Status: Informational
Expires: September 8, 2009 S. Vapiwala Expires: April 2010 S. Vapiwala
J. Karthik J. Karthik
Cisco Systems Cisco Systems
S. Poretsky S. Poretsky
Allot Communications Allot Communications
S. Rao S. Rao
Qwest Communications Qwest Communications
J.L. Le Roux J.L. Le Roux
France Telecom France Telecom
March 8, 2009 October 2009
Methodology for benchmarking MPLS protection mechanisms Methodology for benchmarking MPLS protection mechanisms
draft-ietf-bmwg-protection-meth-05.txt draft-ietf-bmwg-protection-meth-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2009. This Internet-Draft will expire on April 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
Protection Mechanisms Protection Mechanisms
5.2. Failure Detection [TERM-ID] 5.2. Failure Detection [TERM-ID]
Link failure detection time depends on the link type and failure Link failure detection time depends on the link type and failure
detection protocols running. For SONET/SDH, the alarm type (such as detection protocols running. For SONET/SDH, the alarm type (such as
LOS, AIS, or RDI) can be used. Other link types have layer-two LOS, AIS, or RDI) can be used. Other link types have layer-two
alarms, but they may not provide a short enough failure detection alarms, but they may not provide a short enough failure detection
time. Ethernet based links do not have layer 2 failure indicators, time. Ethernet based links do not have layer 2 failure indicators,
and therefore relies on layer 3 signaling for failure detection. and therefore relies on layer 3 signaling for failure detection.
However for directly connected devices, remote fault indication in
the ethernet auto-negotiation scheme could be considered as a type
of layer 2 link failure indicator.
MPLS has different failure detection techniques such as BFD, or use MPLS has different failure detection techniques such as BFD, or use
of RSVP hellos. These methods can be used for the layer 3 failure of RSVP hellos. These methods can be used for the layer 3 failure
indicators required by Ethernet based links, or for some other non- indicators required by Ethernet based links, or for some other non-
Ethernet based links to help improve failure detection time. Ethernet based links to help improve failure detection time.
The test procedures in this document can be used for a local failure The test procedures in this document can be used for a local failure
or remote failure scenarios for comprehensive benchmarking and to or remote failure scenarios for comprehensive benchmarking and to
evaluate failover performance independent of the failure detection evaluate failover performance independent of the failure detection
techniques. techniques.
skipping to change at page 24, line 45 skipping to change at page 25, line 5
3. Timestamp Based Method (TBM): This method of failover 3. Timestamp Based Method (TBM): This method of failover
calculation is based on the timestamp that gets transmitted as calculation is based on the timestamp that gets transmitted as
payload in the packets originated by the generator. The Traffic payload in the packets originated by the generator. The Traffic
Analyzer records the timestamp of the last packet received Analyzer records the timestamp of the last packet received
before the failover event and the first packet after the before the failover event and the first packet after the
failover and derives the time based on the difference between failover and derives the time based on the difference between
these 2 timestamps. Note: The payload could also contain these 2 timestamps. Note: The payload could also contain
sequence numbers for out-of-order packet calculation and sequence numbers for out-of-order packet calculation and
duplicate packets. duplicate packets.
Note: If the primary is configured to be dynamic, and if the primary
is to reroute, make before break should occur from the backup that
is in use to a new alternate primary. If there is any packet loss
seen, it should be added to failover time.
Protection Mechanisms Protection Mechanisms
9. Security Considerations 9. Security Considerations
Documents of this type do not directly affect the security of Documents of this type do not directly affect the security of
Internet or corporate networks as long as benchmarking is not Internet or corporate networks as long as benchmarking is not
performed on devices or systems connected to production networks. performed on devices or systems connected to production networks.
Security threats and how to counter these in SIP and the media Security threats and how to counter these in SIP and the media
layer is discussed in RFC3261, RFC3550, and RFC3711 and various layer is discussed in RFC3261, RFC3550, and RFC3711 and various
other drafts. This document attempts to formalize a set of other drafts. This document attempts to formalize a set of
common methodology for benchmarking performance of failover common methodology for benchmarking performance of failover
 End of changes. 6 change blocks. 
9 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/