Internet DRAFT - draft-satish-6tisch-6top-sf1
draft-satish-6tisch-6top-sf1
6tisch S. Anamalamudi
Internet-Draft Huaiyin Institute of Technology
Intended status: Standards Track B. Liu
Expires: April 30, 2018 M. Zhang
Huawei Technologies
AR. Sangi
Huaiyin Institute of Technology
C. Perkins
Futurewei
S.V.R.Anand
Indian Institute of Science
October 27, 2017
Scheduling Function One (SF1): hop-by-hop Scheduling with RSVP-TE in
6tisch Networks
draft-satish-6tisch-6top-sf1-04
Abstract
This document defines a 6top Scheduling Function called "Scheduling
Function One" (SF1) to reserve, label and schedule the end-to-end
resources hop-by-hop through the Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE). SF1 uses the 6P signaling messages
with a global TrackID to add or delete the cells in L2-bundles of
isolated traffic flows.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 30, 2018.
Anamalamudi, et al. Expires April 30, 2018 [Page 1]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Operation of Scheduling Function One (SF1) . . . . . . . . . 4
2.1. End-to-end Operation . . . . . . . . . . . . . . . . . . 4
2.2. One-hop Operation . . . . . . . . . . . . . . . . . . . . 6
2.2.1. 3-step transaction . . . . . . . . . . . . . . . . . 6
2.2.2. 2-step transaction . . . . . . . . . . . . . . . . . 7
2.3. Reroute and Bandwidth Increase mechanism . . . . . . . . 8
2.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. RSVP-PATH message . . . . . . . . . . . . . . . . . . . . 9
3.2. RSVP-RESV message . . . . . . . . . . . . . . . . . . . . 10
4. Scheduling Function Identifier . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. References . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Scheduling Function Zero (SF0) [I-D.ietf-6tisch-6top-sf0] enables on-
the-fly cell scheduling (ADD/DELETE) between one-hop neighbors for
aggregated (best-effort) traffic flows. In other words, all the
instances from nodeA to nodeB in Figure 1 are scheduled in a single
L3-bundle (IP link).
Anamalamudi, et al. Expires April 30, 2018 [Page 2]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
L3-bundle (Instance-1,Instance-2,...Instance-n)
------------------------------------------------->
nodeA<------------------------------------------------- nodeB
L3-bundle (Instance-1,Instance-2,...Instance-n)
Figure 1: L3-bundle for aggregated traffic flows over one-hop with
SF0.
Some applications (e.g. Industrial M2M) require end-to-end dedicated
L2-bundles to support control/data streams for time-critical
applications [I-D.ietf-detnet-use-cases]. For such applications, the
sender can reserve a dedicated track to the receiver for each
isolated instance. A track is actually a succession of paired
L2-bundles (a receive bundle at the downstream node and a transmit
bundle at the upstream node), which is identified by a global
TrackID. Per-instance L2-bundles need to be scheduled hop-by-hop in
between sender and receiver [I-D.ietf-6tisch-architecture]. In
addition, cells in the scheduled end-to-end track of each instance
may have to be dynamically adapted for bursty time-critical traffic
flows. With one-hop based SF0 cell scheduling, it is difficult to
schedule dedicated end-to-end cells for isolated traffic flows.
Moreover, global bandwidth estimation through Resource Reservation
protocol is required for bandwidth allocation in multi-hop cell
scheduling. This draft specifies a Scheduling Function One (SF1) to
schedule end-to-end dedicated L2-bundles for each instance, and to
dynamically adapt the cells in already scheduled L2-bundles through
RSVP-TE (see Figure 2).
L2-bundle(Instance-1) L2-bundle(Instance-1)
-----------------------> ------------------>
<------------------------ <-------------------
L2-bundle(Instance-1) L2-bundle(Instance-1)
L2-bundle(Instance-2) L2-bundle(Instance-2)
----------------------> ----------------->
Sender<-----------------------nodeB <----------------- Receiver
L2-bundle(Instance-2) L2-bundle(Instance-2)
. .
. .
L2-bundle(Instance-n) L2-bundle(Instance-n)
-----------------------> -------------------->
<------------------------ <--------------------
L2-bundle(Instance-n) L2-bundle(Instance-n)
Figure 2: Dedicated L2-bundles for end-to-end isolated traffic flows
with SF1
Anamalamudi, et al. Expires April 30, 2018 [Page 3]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
2. Operation of Scheduling Function One (SF1)
SF1 is a combination of RSVP-TE and 6P (the 6top protocol
[I-D.ietf-6tisch-6top-protocol]). According to the bandwidth and QoS
requirements of traffic flows, SF1 can schedule, reserve and label
L2-bundles of cells at each hop, build up an end-to-end track
identified by a global TrackID, and dynamically adapt the cells in an
existing track.
Using SF1, the Sender determines when to reserve end-to-end
resources. The following events may trigger the use of SF1:
o The Sender has an outgoing bandwidth requirement for a new instance
to transmit data to Receiver.
o The Sender has a new outgoing bandwidth requirement for an existing
instance to transmit data to Receiver.
In both cases, distributed RSVP-TE is used to provide end-to-end
resource reservations along with scheduling operations. The outcome
of RSVP-TE is a label switching path (LSP) [RFC3209]. In the context
of this draft, a track is actually an LSP, in which the label at each
hop is associated to the reserved cells. And the TrackID is
equivalent to the LSP_ID.
2.1. End-to-end Operation
PATH PATH PATH
+-----------+ +-----------+ +-----------+
| | | | | |
| v | v | v
+--------+ +--------+ +--------+ +--------+
| Sender | | Node A | | Node B | |Receiver|
+--------+ +--------+ +--------+ +--------+
^ 6P | ^ 6P | ^ 6P |
| Trans. | | Trans. | | Trans. |
|<--------->| |<--------->| |<--------->|
+-----------+ +-----------+ +-----------+
RESV RESV RESV
Figure 3: End-to-end Operation in SF1
Anamalamudi, et al. Expires April 30, 2018 [Page 4]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
+--------+ +--------+ +--------+
| Sender |-----PATH----->|Receiver|-----RESV----->| Sender |
+--------+ +--------+ +--------+
|----------E2E Track Reservation---------|
|-----------------E2E Timeout---------------|
Figure 4: End-to-end timeout in SF1
It is assumed that an end-to-end route path is already available, for
instance by using AODV-RPL [I-D.ietf-roll-aodv-rpl] routing. To
initiate the track reservation, the sender sends the RSVP-PATH
message to the receiver along the route. The PATH message describes
the characteristics of the traffic flow and gathers information along
the route to help the receiver(s) construct an appropriate
reservation request [RFC2205]. Upon arrival of the PATH message, the
receiver sends an RSVP-RESV message upstream to the sender. At each
hop, the cells to be reserved are negotiated between 2 neighbors with
the help of 6P transactions. If one-hop reservation succeeds, the
downstream node assigns a label, which is associated to the selected
cells, to the upstream node. And the label is also associated to the
track whose TrackID is encapsulated in the FILTER_SPEC of the RESV
message. If one-hop reservation fails at an intermediate node, the
node SHOULD send a ResvErr message to the receiver and all the nodes
along the downstream route to tear down the reserved resources. When
the RESV message arrives at the sender before the end-to-end timeout,
an end-to-end track is built successfully. If no RESV message is
received at the sender when timeout, the track reservation fails.
The end-to-end data transmission is achieved through Track Forwarding
[I-D.ietf-6tisch-architecture] that can be seen as a G-MPLS operation
in which the explicit label at each hop is associated to an implicit
label, i.e., the reserved cells. When transmitting data, the sender
identifies the track to be used based on Sender and Receiver IP
addresses and RPLInstanceID of the packet. At each hop, the packet
is transmitted using the reserved L2-bundle of cells on this track.
Anamalamudi, et al. Expires April 30, 2018 [Page 5]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
+--------------+ <-Data transmission in end-to-end Track->
| IPv6 | Sender Receiver
+--------------+ | |
| 6LoWPAN | | |
+--------------+ | nodeB |
| 6top | | +----+ |
+--------------+ | | | |
| TSCH MAC | | | | |
+--------------+ | | | |
| LLN PHY | | L2-Bundle | | L2-Bundle |
+--------------+ +----------------+ +---------------+
<--Dedicated cells for each Instance-->
Figure 5: Track Forwarding
2.2. One-hop Operation
Upon arrival of the PATH message at an application receiver, the
SENDER_TSPEC and ADSPEC objects are utilized to select the resource
reservation parameters in FLOWSPEC of the RESV message. Since RSVP
provides receiver initiated resource reservation setup, the
scheduling operation proceeds upstream from receiver to sender. In
6P the resources are represented as cells, thus the bandwidth can be
interpreted as the number of cells, and the QoS can be interpreted as
the constraints on cells, e.g. the priority of slotframe, the
slotOffset and channelOffset of cells. Therefore, the bandwidth and
QoS parameters in FLOWSPEC need to be mapped to number and
constraints of cells in the 6P transaction.
In this document, when there are two neighbor nodes, the upstream
node is named Node A, and the downstream node is named Node B. If
Node B is the receiver, the cell reservation is initiated by the
arrival of a PATH message. If node B is an intermediate node, the
reservation is initiated by the arrival of an RESV message from
downstream. The cell reservation begins with 6P transactions, which
can be 3-step or 2-step [I-D.ietf-6tisch-6top-protocol]. The
operation of RESV message with these two kinds of transactions is
specified as follows.
2.2.1. 3-step transaction
As illustrated in Figure 6, Node B first determines whether it can
provide enough qualified cells to receive traffic from Node A,
according to the parameters in FLOWSPEC. If not, Node B SHOULD send
a ResvErr message. Otherwise, Node B transmits a 6P Request message
to Node A with the slotFrame_ID in the metadata field. The type of
the Request message (ADD or DELETE) is decided by comparing the the
required cells and the currently reserved cells. In a 3-step
Anamalamudi, et al. Expires April 30, 2018 [Page 6]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
transaction, the "CellList" field in the 6P request SHOULD be empty.
The timeout for the 6P transaction is as defined in
[I-D.ietf-6tisch-6top-protocol]. Node A checks the associated
slotframe and proposes a candidate CellList. Then a 6P Response
message is sent back to Node B. If Node B is able to select expected
number of cells in this candidate CellList, it sends an RESV message
to Node A, in which the 6P Confirmation message indicating the
selected cells is encapsulated as the 6P OPERATION object, and the
label is assigned as defined in Section 3.2. Otherwise, the Node B
can choose to initiate another 6P transaction on another slotframe
which can fulfill the QoS requirement. If all the 6P transactions
fail, Node B SHOULD send a ResvErr message all the way to the
receiver to tear down all the reserved resources. When the RESV
message arrives at Node A, the L2-bundle between Node A and Node B is
installed.
Node A Node B
-------------- --------------
| | FLOWSPEC:
| | bandwidth and
| | QoS requirements
| |
| | Map bandwidth
| | and QoS to cells
| 6P Request with |
| an empty CellList | timeout
|<--------------------------| ---
| | |
| 6P Response with | |
timeout | candidate CellList | |
--- |-------------------------->| X
| | RESV carrying 6P |
| | Confirmation with |
| | selected CellList |
X |<--------------------------|Cells reserved
Cells reserved| |
Label assigned| |
Figure 6: Operation of RESV message with 3-step transaction.
2.2.2. 2-step transaction
As illustrated in Figure 7, Node B SHOULD provide a candidate
CellList which can fulfill the requirements in the 6P Request
message, then Node A sends back the 6P Response message with a
selected CellList. If the number of cells in the selected CellList
is what Node B expects, Node B sends an RESV message to Node A
including an assigned label and without the 6P OPERATION object. The
Anamalamudi, et al. Expires April 30, 2018 [Page 7]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
error handling mechanism is the same as in the 3-step transaction
fashion.
Node A Node B
-------------- --------------
| | FLOWSPEC:
| | bandwidth and
| | QoS requirements
| |
| | Map bandwidth and
| | QoS to cells
| 6P Request and |
| candidate CellList | timeout
|<--------------------------| ---
| | |
| 6P Response with | |
timeout | selected CellList | |
--- |-------------------------->| X
| | |
| | |
| | RESV |
X |<--------------------------|Cells reserved
Cells reserved| |
Label assigned| |
Figure 7: Operation of RESV message with 2-step transaction.
2.3. Reroute and Bandwidth Increase mechanism
Whenever the sender needs to establish a new tunnel that can maintain
resource reservations without double counting (at any particular
intermediate node) the resources with an existing tunnel, then the
"RSVP reroute mechanism" is initiated [RFC3209]. With this
operation, bandwidth can be increased or decreased end-to-end in the
tunnel. The detailed explanation of the reroute mechanism is
explained in [RFC3209].
2.4. Error Codes
The detailed explanation of PathErr and ResvErr with different
ERROR_SPEC to handle Scheduling and 6P operation errors will be
described in later specification.
3. Message Format
Anamalamudi, et al. Expires April 30, 2018 [Page 8]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
3.1. RSVP-PATH message
The basic RSVP-PATH message [RFC2205] is used to carry the "Sender
Traffic Specification" along with "characterization parameters" from
sender to receiver. Since RSVP treats objects as opaque data, it is
permissible to use another protocol element (e.g. GMPLS, 6P, SF1) as
an object in a RSVP-PATH message.
The format of the PATH message that supports 6tisch scheduling
capabilities (6P and SF1) is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SF1 OPERATION REQUEST> ]
[ <6P OPERATION REQUEST> ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The format of the Generalized Label Request Object in PATH message
is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Generalized Label Request describes the requirement of
communication characteristics to support the 6TiSCH-LSP being
requested. The Generalized Label Request object is set by the
ingress node (6LR), transparently passed by transit nodes, and used
by the egress node (6LR).
Anamalamudi, et al. Expires April 30, 2018 [Page 9]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
1. LSP Encoding Type (8 bits): Indicates the encoding of the LSP
being requested.
+---------+--------------+
| Value | Type |
+---------+--------------+
| TBD | Timeslot |
+---------+--------------+
2. Switching Type (8 bits): Indicates the type of switching that
should be performed on a particular link.
+---------+-------------------------------------+
| Value | Type |
+---------+-------------------------------------+
| 100 |Time-Division-Multiplex (TDM) Capable|
+---------+-------------------------------------+
3. G-PID (8 bits): An identifier of the payload carried by an LSP,
i.e., an identifier of the client layer of that LSP.
+---------+-----------------------+------------+
| Value | Type | Technology |
+---------+-----------------------+------------+
| TBD |Wireless PAN (802.15.4)| TSCH |
+---------+-----------------------+------------+
"SF1 OPERATION REQUEST" and "6P OPERATION REQUEST" are added in the
PATH message to check for 6tisch scheduling capabilities within the
intermediate nodes from sender to receiver. The "Timeslot Switching
Capability" (TSC) is used as an implicit label to switch the cell at
intermediate nodes [RFC3473]. "LABEL_REQUEST" in path message should
be set to "Timeslot Switching Capability". If an intermediate node
does not support the TSC or "6P transactions" or "SF1 operation" then
it MUST send a "PathErr" message back to application. At the sender,
the combination of sender and receiver IP addresses and the
RPLInstanceID is mapped to a 16-bit identifier. The sender uses this
identifier as the Track ID, and encapsulates it in the
SENDER_TEMPLATE.
3.2. RSVP-RESV message
The basic RSVP-RESV messages [RFC2205] are transmitted upstream from
receiver to sender to provide resource reservation as well as label
distribution. In this specification, hop-by-hop scheduling is
extended to support both resource reservation and label distribution.
The current specification is only defined for unicast point-to-point
traffic flows, i.e., Fixed Filter (FF) reservation style.
Anamalamudi, et al. Expires April 30, 2018 [Page 10]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
The format of the RESV message that supports 6tisch scheduling
capabilities (6P and SF1) is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <6P OPERATION> ]
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
The 6P OPERATION object encapsulates the 6P message. The tuple
(slotFrame_ID, CellList) indicating the reserved cells is mapped to a
32-bit unsigned integer, which is used as the label to be assigned to
the upstream node. The format of the LABEL object (in the flow
descriptor) conforms to the Type 1 Label defined in [RFC3473].
4. Scheduling Function Identifier
The Scheduling Function Identifier (SFID) of SF1 is
IANA_SFID_SF1(TBD).
5. IANA Considerations
IANA is requested to allocate a new Scheduling Function
(IANA_SFID_SF1) from the SF space of Scheduling Functions defined in
[I-D.ietf-6tisch-6top-sf0]
6. Security Considerations
TODO
7. References
7.1. References
[I-D.ietf-6tisch-6top-protocol]
Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
(6P)", draft-ietf-6tisch-6top-protocol-09 (work in
progress), October 2017.
Anamalamudi, et al. Expires April 30, 2018 [Page 11]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
7.2. Informative References
[I-D.ietf-6tisch-6top-sf0]
Dujovne, D., Grieco, L., Palattella, M., and N. Accettura,
"6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf-
6tisch-6top-sf0-05 (work in progress), July 2017.
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), August 2017.
[I-D.ietf-detnet-use-cases]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y.,
Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,
X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D.,
Geng, X., Dujovne, D., and M. Seewald, "Deterministic
Networking Use Cases", draft-ietf-detnet-use-cases-13
(work in progress), September 2017.
[I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S.
Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy
Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in
progress), September 2017.
Authors' Addresses
Anamalamudi, et al. Expires April 30, 2018 [Page 12]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
Satish Anamalamudi
Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District
Huaian 223001
China
Email: satishnaidu80@gmail.com
Bing Liu
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: remy.liubing@huawei.com
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: zhangmingui@huawei.com
Abdur Rashid Sangi
Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District
Huaian 223001
P.R. China
Email: sangi_bahrian@yahoo.com
Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara 95050
Unites States
Email: charliep@computer.org
Anamalamudi, et al. Expires April 30, 2018 [Page 13]
Internet-Draft draft-satish-6tisch-6top-sf1 October 2017
S.V.R Anand
Indian Institute of Science
Bangalore
560012
India
Email: anand@ece.iisc.ernet.in
Anamalamudi, et al. Expires April 30, 2018 [Page 14]
