draft-ietf-tictoc-multi-path-synchronization-02.txt   draft-ietf-tictoc-multi-path-synchronization-03.txt 
Network Working Group A. Shpiner Network Working Group A. Shpiner
Internet Draft Technion - Israel Institute of Technology Internet Draft Technion - Israel Institute of Technology
Intended status: Experimental R. Tse Intended status: Experimental R. Tse
Expires: October 2015 C. Schelp Expires: April 2016 C. Schelp
PMC-Sierra PMC-Sierra
T. Mizrahi T. Mizrahi
Marvell Marvell
April 19, 2015 October 18, 2015
Multi-Path Time Synchronization Multi-Path Time Synchronization
draft-ietf-tictoc-multi-path-synchronization-02.txt draft-ietf-tictoc-multi-path-synchronization-03.txt
Abstract Abstract
Clock synchronization protocols are very widely used in IP-based Clock synchronization protocols are very widely used in IP-based
networks. The Network Time Protocol (NTP) has been commonly deployed networks. The Network Time Protocol (NTP) has been commonly deployed
for many years, and the last few years have seen an increasingly for many years, and the last few years have seen an increasingly
rapid deployment of the Precision Time Protocol (PTP). As time- rapid deployment of the Precision Time Protocol (PTP). As time-
sensitive applications evolve, clock accuracy requirements are sensitive applications evolve, clock accuracy requirements are
becoming increasingly stringent, requiring the time synchronization becoming increasingly stringent, requiring the time synchronization
protocols to provide high accuracy. Slave Diversity is a recently protocols to provide high accuracy. Slave Diversity is a recently
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 October 19, 2015. This Internet-Draft will expire on April 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction...................................................3
2. Conventions Used in this Document ............................ 5 2. Conventions Used in this Document..............................5
2.1. Abbreviations ........................................... 5 2.1. Abbreviations.............................................5
2.2. Terminology ............................................. 5 2.2. Terminology...............................................5
3. Multiple Paths in IP Networks ................................ 5 3. Multiple Paths in IP Networks..................................5
3.1. Load Balancing .......................................... 5 3.1. Load Balancing............................................5
3.2. Using Multiple Paths Concurrently ....................... 6 3.2. Using Multiple Paths Concurrently.........................6
3.3. Two-Way Paths ........................................... 6 3.3. Two-Way Paths.............................................6
4. Solution Overview ............................................ 6 4. Solution Overview..............................................6
4.1. Path Configuration and Identification ................... 6 4.1. Path Configuration and Identification.....................6
4.2. Combining ............................................... 7 4.2. Combining.................................................7
5. Multi-Path Time Synchronization Protocols over IP Networks ... 7 5. Multi-Path Time Synchronization Protocols over IP Networks.....7
5.1. Single-Ended Multi-Path Synchronization ................. 8 5.1. Single-Ended Multi-Path Synchronization...................8
5.1.1. Single-Ended MPPTP Synchronization Message Exchange 8 5.1.1. Single-Ended MPPTP Synchronization Message Exchange..8
5.1.2. Single-Ended MPNTP Synchronization Message Exchange 9 5.1.2. Single-Ended MPNTP Synchronization Message Exchange..9
5.2. Dual-Ended Multi-Path Synchronization .................. 10 5.2. Dual-Ended Multi-Path Synchronization....................10
5.2.1. Dual-Ended MPPTP Synchronization Message Exchange . 10 5.2.1. Dual-Ended MPPTP Synchronization Message Exchange...10
5.2.2. Dual-Ended MPNTP Synchronization Message Exchange . 11 5.2.2. Dual-Ended MPNTP Synchronization Message Exchange...11
5.3. Using Traceroute for Path Discovery .................... 12 5.3. Using Traceroute for Path Discovery......................12
5.4. Using Unicast Discovery for MPPTP ...................... 12 5.4. Using Unicast Discovery for MPPTP........................12
6. Combining Algorithm ......................................... 13 6. Combining Algorithm...........................................13
7. Security Considerations ..................................... 13 7. Security Considerations.......................................13
8. IANA Considerations ......................................... 13 8. IANA Considerations...........................................13
9. Acknowledgments ............................................. 13 9. Acknowledgments...............................................13
10. References ................................................. 13 10. References...................................................13
10.1. Normative References .................................. 13 10.1. Normative References....................................13
10.2. Informative References ................................ 14 10.2. Informative References..................................14
1. Introduction 1. Introduction
The two most common time synchronization protocols in IP networks are The two most common time synchronization protocols in IP networks are
the Network Time Protocol [NTP], and the Precision Time Protocol the Network Time Protocol [NTP], and the Precision Time Protocol
(PTP), defined in the IEEE 1588 standard [IEEE1588]. (PTP), defined in the IEEE 1588 standard [IEEE1588].
The accuracy of the time synchronization protocols directly depends The accuracy of the time synchronization protocols directly depends
on the stability and the symmetry of propagation delays on both on the stability and the symmetry of propagation delays on both
directions between the master and slave clocks. Depending on the directions between the master and slave clocks. Depending on the
nature of the underlying network, time synchronization protocol nature of the underlying network, time synchronization protocol
skipping to change at page 5, line 12 skipping to change at page 5, line 12
protocols; a variant that requires both master and slave nodes to protocols; a variant that requires both master and slave nodes to
support the multi-path protocol, referred to as the dual-ended support the multi-path protocol, referred to as the dual-ended
variant, and a backward compatible variant that allows a multi-path variant, and a backward compatible variant that allows a multi-path
clock to connect to a conventional single-path clock, referred to as clock to connect to a conventional single-path clock, referred to as
the single-ended variant. the single-ended variant.
2. Conventions Used in this Document 2. Conventions Used in this Document
2.1. Abbreviations 2.1. Abbreviations
BMC Best Master Clock [IEEE1588] BMC Best Master Clock [IEEE1588]
ECMP Equal Cost Multiple Path ECMP Equal Cost Multiple Path
LAN Local Area Network LAN Local Area Network
MPNTP Multi-Path Network Time Protocol MPNTP Multi-Path Network Time Protocol
MPPTP Multi-Path Precision Time Protocol MPPTP Multi-Path Precision Time Protocol
NTP Network Time Protocol [NTP] NTP Network Time Protocol [NTP]
PTP Precision Time Protocol [IEEE1588] PTP Precision Time Protocol [IEEE1588]
2.2. Terminology 2.2. Terminology
In the NTP terminology, a time synchronization protocol is run In the NTP terminology, a time synchronization protocol is run
between a client and a server, while PTP uses the terms master and between a client and a server, while PTP uses the terms master and
slave. Throughout this document, the sections that refer to both PTP slave. Throughout this document, the sections that refer to both PTP
and NTP generically use the terms master and slave. and NTP generically use the terms master and slave.
3. Multiple Paths in IP Networks 3. Multiple Paths in IP Networks
skipping to change at page 8, line 42 skipping to change at page 8, line 42
the network as N independent clocks, using N IP addresses, as well as the network as N independent clocks, using N IP addresses, as well as
N clock identity values (in PTP). Thus, the usage of multiple slave N clock identity values (in PTP). Thus, the usage of multiple slave
identities by a slave clock is transparent from the master's point of identities by a slave clock is transparent from the master's point of
view, such that it treats each of the identities as a separate slave view, such that it treats each of the identities as a separate slave
clock. clock.
5.1.1. Single-Ended MPPTP Synchronization Message Exchange 5.1.1. Single-Ended MPPTP Synchronization Message Exchange
The single-ended MPPTP message exchange procedure is as follows. The single-ended MPPTP message exchange procedure is as follows.
o Each single-ended MPPTP clock has a fixed set of N IP addresses o Each single-ended MPPTP clock has a fixed set of N IP addresses
and N corresponding clockIdentities. Each clock arbitrarily and N corresponding clockIdentities. Each clock arbitrarily
defines one of its IP addresses and clockIdentity values as the defines one of its IP addresses and clockIdentity values as the
clock primary identity. clock primary identity.
o A single-ended MPPTP port sends Announce messages only from its o A single-ended MPPTP port sends Announce messages only from its
primary identity, according to the BMC algorithm. primary identity, according to the BMC algorithm.
o The BMC algorithm at each clock determines the master, based on o The BMC algorithm at each clock determines the master, based on
the received Announce messages. the received Announce messages.
o A single-ended MPPTP port that is in the 'slave' state uses o A single-ended MPPTP port that is in the 'slave' state uses
unicast negotiation to request the master to transmit unicast unicast negotiation to request the master to transmit unicast
messages to each of the N slave clock identities. The slave port messages to each of the N slave clock identities. The slave port
periodically sends N Signaling messages to the master, using each periodically sends N Signaling messages to the master, using each
of its N identities. The Signaling message includes the of its N identities. The Signaling message includes the
REQUEST_UNICAST_TRANSMISSION_TLV. REQUEST_UNICAST_TRANSMISSION_TLV.
o The master periodically sends unicast Sync messages from its o The master periodically sends unicast Sync messages from its
primary identity, identified by the sourcePortIdentity and IP primary identity, identified by the sourcePortIdentity and IP
address, to each of the slave identities. address, to each of the slave identities.
o The slave, upon receiving a Sync message, identifies its path o The slave, upon receiving a Sync message, identifies its path
according to the destination IP address. The slave sends a according to the destination IP address. The slave sends a
Delay_Req unicast message to the primary identity of the master. Delay_Req unicast message to the primary identity of the master.
The Delay_Req is sent using the slave identity corresponding to The Delay_Req is sent using the slave identity corresponding to
the path the Sync was received through. Note that the rate of the path the Sync was received through. Note that the rate of
Delay_Req messages may be lower than the Sync message rate, and Delay_Req messages may be lower than the Sync message rate, and
thus a Sync message is not necessarily followed by a Delay_Req. thus a Sync message is not necessarily followed by a Delay_Req.
o The master, in response to a Delay_Req message from the slave, o The master, in response to a Delay_Req message from the slave,
responds with a Delay_Resp message using the IP address and responds with a Delay_Resp message using the IP address and
sourcePortIdentity from the Delay_Req message. sourcePortIdentity from the Delay_Req message.
o Upon receiving the Delay_Resp message, the slave identifies the o Upon receiving the Delay_Resp message, the slave identifies the
path using the destination IP address and the path using the destination IP address and the
requestingPortIdentity. The slave can then compute the requestingPortIdentity. The slave can then compute the
corresponding path delay and the offset from the master. corresponding path delay and the offset from the master.
o The slave combines the information from all negotiated paths. o The slave combines the information from all negotiated paths.
5.1.2. Single-Ended MPNTP Synchronization Message Exchange 5.1.2. Single-Ended MPNTP Synchronization Message Exchange
The single-ended MPNTP message exchange procedure is as follows. The single-ended MPNTP message exchange procedure is as follows.
o A single-ended MPNTP client has N separate identities, i.e., N IP o A single-ended MPNTP client has N separate identities, i.e., N IP
addresses. The assumption is that the server information, addresses. The assumption is that the server information,
including its IP address is known to the NTP clients. including its IP address is known to the NTP clients.
o A single-ended MPNTP client initiates the NTP protocol with an NTP o A single-ended MPNTP client initiates the NTP protocol with an NTP
server N times, using each of its N identities. server N times, using each of its N identities.
o The NTP protocol is maintained between the server and each of the o The NTP protocol is maintained between the server and each of the
N client identities. N client identities.
o The client sends NTP messages to the master using each of its N o The client sends NTP messages to the master using each of its N
identities. identities.
o The server responds to the client's NTP messages using the IP o The server responds to the client's NTP messages using the IP
address from the received NTP packet. address from the received NTP packet.
o The client, upon receiving an NTP packet, uses the IP destination o The client, upon receiving an NTP packet, uses the IP destination
address to identify the path it came through, and uses the time address to identify the path it came through, and uses the time
information accordingly. information accordingly.
o The client combines the information from all paths. o The client combines the information from all paths.
5.2. Dual-Ended Multi-Path Synchronization 5.2. Dual-Ended Multi-Path Synchronization
In dual-ended multi-path synchronization each clock has N IP In dual-ended multi-path synchronization each clock has N IP
addresses. Time synchronization messages are exchanged between some addresses. Time synchronization messages are exchanged between some
of the combinations of {master IP, slave IP} addresses, allowing of the combinations of {master IP, slave IP} addresses, allowing
multiple paths between the master and slave. Note that the actual multiple paths between the master and slave. Note that the actual
number of paths between the master and slave may be less than the number of paths between the master and slave may be less than the
number of chosen {master, slave} IP address pairs. number of chosen {master, slave} IP address pairs.
Once the multiple two-way connections are established, a separate Once the multiple two-way connections are established, a separate
synchronization protocol exchange instance is run through each of synchronization protocol exchange instance is run through each of
them. them.
5.2.1. Dual-Ended MPPTP Synchronization Message Exchange 5.2.1. Dual-Ended MPPTP Synchronization Message Exchange
The dual-ended MPPTP message exchange procedure is as follows. The dual-ended MPPTP message exchange procedure is as follows.
o Every clock has N IP addresses, but uses a single clockIdentity. o Every clock has N IP addresses, but uses a single clockIdentity.
o The BMC algorithm at each clock determines the master. The master o The BMC algorithm at each clock determines the master. The master
is identified by its clockIdentity, allowing other clocks to know is identified by its clockIdentity, allowing other clocks to know
the multiple IP addresses it uses. the multiple IP addresses it uses.
o When a clock sends an Announce message, it sends it from each of o When a clock sends an Announce message, it sends it from each of
its IP addresses with its clockIdentity. its IP addresses with its clockIdentity.
o A dual-ended MPPTP port that is in the 'slave' state uses unicast o A dual-ended MPPTP port that is in the 'slave' state uses unicast
negotiation to request the master to transmit unicast messages to negotiation to request the master to transmit unicast messages to
some or all of its N_s IP addresses. This negotiation is done some or all of its N_s IP addresses. This negotiation is done
individually between a slave IP address and the corresponding individually between a slave IP address and the corresponding
master IP address that the slave desires a connection with. The master IP address that the slave desires a connection with. The
slave port periodically sends Signaling messages to the master, slave port periodically sends Signaling messages to the master,
using some or all of its N_s IP addresses as source, to the using some or all of its N_s IP addresses as source, to the
corresponding master's N_m IP addresses. The Signaling message corresponding master's N_m IP addresses. The Signaling message
includes the REQUEST_UNICAST_TRANSMISSION_TLV. includes the REQUEST_UNICAST_TRANSMISSION_TLV.
o The master periodically sends unicast Sync messages from each of o The master periodically sends unicast Sync messages from each of
its IP addresses to the corresponding slave IP addresses for which its IP addresses to the corresponding slave IP addresses for which
a unicast connection was negotiated. a unicast connection was negotiated.
o The slave, upon receiving a Sync message, identifies its path o The slave, upon receiving a Sync message, identifies its path
according to the {source, destination} IP addresses. The slave according to the {source, destination} IP addresses. The slave
sends a Delay_Req unicast message, swapping the source and sends a Delay_Req unicast message, swapping the source and
destination IP addresses from the Sync message. Note that the rate destination IP addresses from the Sync message. Note that the rate
of Delay_Req messages may be lower than the Sync message rate, and of Delay_Req messages may be lower than the Sync message rate, and
thus a Sync message is not necessarily followed by a Delay_Req. thus a Sync message is not necessarily followed by a Delay_Req.
o The master, in response to a Delay_Req message from the slave, o The master, in response to a Delay_Req message from the slave,
responds with a Delay_Resp message using the sourcePortIdentity responds with a Delay_Resp message using the sourcePortIdentity
from the Delay_Req message, and swapping the IP addresses from the from the Delay_Req message, and swapping the IP addresses from the
Delay_Req. Delay_Req.
o Upon receiving the Delay_Resp message, the slave identifies the o Upon receiving the Delay_Resp message, the slave identifies the
path using the {source, destination} IP address pair. The slave path using the {source, destination} IP address pair. The slave
can then compute the corresponding path delay and the offset from can then compute the corresponding path delay and the offset from
the master. the master.
o The slave combines the information from all negotiated paths. o The slave combines the information from all negotiated paths.
5.2.2. Dual-Ended MPNTP Synchronization Message Exchange 5.2.2. Dual-Ended MPNTP Synchronization Message Exchange
The MPNTP message exchange procedure is as follows. The MPNTP message exchange procedure is as follows.
o Each NTP clock has a set of N IP addresses. The assumption is that o Each NTP clock has a set of N IP addresses. The assumption is that
the server information, including its multiple IP addresses is the server information, including its multiple IP addresses is
known to the NTP clients. known to the NTP clients.
o The MPNTP client chooses N_svr of the N server IP addresses and o The MPNTP client chooses N_svr of the N server IP addresses and
N_c of the N client IP addresses and initiates the N_svr*N_c N_c of the N client IP addresses and initiates the N_svr*N_c
instances of the protocol, one for each {server IP, client IP} instances of the protocol, one for each {server IP, client IP}
pair, allowing the client to combine the information from the pair, allowing the client to combine the information from the
N_s*N_c paths. N_s*N_c paths.
(N_svr and N_c indicate the number of IP addresses of the server (N_svr and N_c indicate the number of IP addresses of the server
and client, respectively, which a client chooses to connect with) and client, respectively, which a client chooses to connect with)
o The client sends NTP messages to the master using each of the o The client sends NTP messages to the master using each of the
source-destination address combinations. source-destination address combinations.
o The server responds to the client's NTP messages using the IP o The server responds to the client's NTP messages using the IP
address combination from the received NTP packet. address combination from the received NTP packet.
o Using the {source, destination} IP address pair in the received o Using the {source, destination} IP address pair in the received
packets, the client identifies the path, and performs its packets, the client identifies the path, and performs its
computations for each of the paths accordingly. computations for each of the paths accordingly.
o The client combines the information from all paths. o The client combines the information from all paths.
5.3. Using Traceroute for Path Discovery 5.3. Using Traceroute for Path Discovery
The protocols presented above use multiple IP addresses in a single The protocols presented above use multiple IP addresses in a single
clock to create multiple paths. However, although each two-way path clock to create multiple paths. However, although each two-way path
is defined by a different {master, slave} address pair, some of the is defined by a different {master, slave} address pair, some of the
IP address pairs may traverse exactly the same network path, making IP address pairs may traverse exactly the same network path, making
them redundant. Traceroute-based path discovery can be used for them redundant. Traceroute-based path discovery can be used for
filtering only the IP addresses that obtain diverse paths. 'Paris filtering only the IP addresses that obtain diverse paths. 'Paris
Traceroute' [PARIS] and 'TraceFlow' [TRACEFLOW] are examples of tools Traceroute' [PARIS] and 'TraceFlow' [TRACEFLOW] are examples of tools
skipping to change at page 12, line 38 skipping to change at page 12, line 38
5.4. Using Unicast Discovery for MPPTP 5.4. Using Unicast Discovery for MPPTP
As presented above, MPPTP uses Announce messages and the BMC As presented above, MPPTP uses Announce messages and the BMC
algorithm to discover the master. The unicast discovery option of PTP algorithm to discover the master. The unicast discovery option of PTP
can be used as an alternative. can be used as an alternative.
When using unicast discovery the MPPTP slave ports maintain a list of When using unicast discovery the MPPTP slave ports maintain a list of
the IP addresses of the master. The slave port uses unicast the IP addresses of the master. The slave port uses unicast
negotiation to request unicast service from the master, as follows: negotiation to request unicast service from the master, as follows:
o In single-ended MPPTP, the slave uses unicast negotiation from o In single-ended MPPTP, the slave uses unicast negotiation from
each of its identities to the master's (only) identity. each of its identities to the master's (only) identity.
o In dual-ended MPPTP, the slave uses unicast negotiation from its o In dual-ended MPPTP, the slave uses unicast negotiation from its
IP addresses, each to a corresponding master IP address to request IP addresses, each to a corresponding master IP address to request
unicast synchronization messages. unicast synchronization messages.
Afterwards, the message exchange continues as described in sections Afterwards, the message exchange continues as described in sections
5.1.1. and 5.2.1. 5.1.1. and 5.2.1.
The unicast discovery option can be used in networks that do not The unicast discovery option can be used in networks that do not
support multicast or in networks in which the master clocks are known support multicast or in networks in which the master clocks are known
in advance. In particular, unicast discovery avoids multicasting in advance. In particular, unicast discovery avoids multicasting
Announce messages. Announce messages.
skipping to change at page 14, line 33 skipping to change at page 14, line 33
[HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High [HIGH-AVAI] P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, "High
availability IEEE 1588 nodes over IEEE 802.1 aq availability IEEE 1588 nodes over IEEE 802.1 aq
Shortest Path Bridging networks" ISPCS, 2013. Shortest Path Bridging networks" ISPCS, 2013.
[KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi- [KALMAN] G. Giorgi, C. Narduzzi, "Kalman filtering for multi-
path network synchronization" ISPCS, 2014. path network synchronization" ISPCS, 2014.
[MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time [MULTI] A. Shpiner, Y. Revah, T. Mizrahi, "Multi-path Time
Protocols" ISPCS, 2013. Protocols" ISPCS, 2013.
[NTP2] Mills, D.L., "Internet time synchronization: the
Network Time Protocol", IEEE Trans. Communications
COM-39, 10 (October 1991), 1482-1493.
[NTP3] Mills, D.L., "Improved algorithms for synchronizing
computer network clocks", IEEE/ACM Trans. Networks 3,
3(June 1995), 245-254.
[PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira,
"Measuring Load-balanced Paths in the Internet", IMC, "Measuring Load-balanced Paths in the Internet", IMC,
2007. 2007.
[PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring [PARIS2] B. Augustin, T. Friedman, and R. Teixeira, "Measuring
Multipath Routing in the Internet", IEEE/ACM Multipath Routing in the Internet", IEEE/ACM
Transactions on Networking, 19(3), p. 830 - 840, June Transactions on Networking, 19(3), p. 830 - 840, June
2011. 2011.
[SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to [SLAVEDIV] T. Mizrahi, "Slave Diversity: Using Multiple Paths to
Improve the Accuracy of Clock Synchronization Improve the Accuracy of Clock Synchronization
Protocols", ISPCS, 2012. Protocols", ISPCS, 2012.
[TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols [TICTOCSEC] T. Mizrahi, "Security Requirements of Time Protocols
in Packet Switched Networks", IETF, RFC 7384, 2015. in Packet Switched Networks", IETF, RFC 7384, 2014.
[TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P. [TRACEFLOW] J. Narasimhan, B. V. Venkataswami, R. Groves and P.
Hoose, "Traceflow", IETF, draft-janapath-intarea- Hoose, "Traceflow", IETF, draft-janapath-intarea-
traceflow, work in progress, 2012. traceflow, work in progress, 2012.
Authors' Addresses Authors' Addresses
Alex Shpiner Alex Shpiner
Department of Electrical Engineering Department of Electrical Engineering
Technion - Israel Institute of Technology Technion - Israel Institute of Technology
 End of changes. 47 change blocks. 
80 lines changed or deleted 72 lines changed or added

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