[6tisch] 答复: Pascal's questions on draft-satish-6tisch-6top-sf1-00.txt

["Satish Anamalamudi (Satish Anamalamudi)" <[e-mail]>]

Hello Pascal,

Thanks a lot for your comments and suggestions. Please, see my reply with [SA].

With Regards,
Satish
发件人: Pascal Thubert (pthubert) [mailto:[e-mail]]
发送时间: 2016年6月10日 19:42
收件人: Satish Anamalamudi (Satish Anamalamudi)
抄送: [e-mail]
主题: Pascal's questions on draft-satish-6tisch-6top-sf1-00.txt

Hello Satish and authors:

1)
It is not fully decided whether different global instances (RFC 6550) would use different bundles. Maybe they should.

For tracks, we decided to use local instance, which means that the instance ID is the combination of the source (or destination) and the instance ID in the RPI.

Is this compatible with your work?

[SA] Yes Pascal. Track-ID creation is based on <Source IP address, local RPLInstanceID>. Based on yesterday's meeting, I will update the draft stating that  it is also possible to generate Track-ID based on <Destination IP address, RPLInstanceID>.

2)

These sentences back to back are hard to figure. Could you reword?

                                               How exactly the end-to-end
   resources are reserved is out-of-scope in this document.
   How exactly the reserved resources are going to be scheduled for end-
   to-end path of each instance with 6P protocol is defined with SF1.

[SA] Sure Pascal. I will update it in the draft and submit  “01”  version soon.

3)

I the following text: should the intermediate node be allowed to add cells to compensate for bad ETX?


                Hence, the dynamic adoption (OTF) of cells should be
   always triggered by the Source node.  In other words, intermediate
   nodes are not able to dynamically adapt(add/delete) the cells in an
   ongoing instance

[SA] What I would like to say about the above statement is, only source node should trigger Increase/Decrease the cells based on its traffic. Intermediate nodes may replace the existing cell with a new cell from the allocated chunk for a bad ETX."

4)

Section “4.3.  SF1 Allocation policy “ has an allocation policy that emulates SF0. Why is that needed? I understand that for SF1, the updates are rare and forced by the RSVP-TE protocol, aren’t they?

[SA] With a resource reservation protocol, nodes will know the bandwidth required for a specific instance. Now, it is the responsibility of SF1 allocation policy to map the bandwidth to required number of cells. To handle
the dynamic cell adaptation and bad ETX, bandwidth over-provisioning is done during the chunk allocation from PCE or distributed way. Later, SF1 will trigger its allocation policy to dynamically increase/decrease the Required
Cells based on traffic conditions, (or) can replace the allocated cell with new cell during bad ETX].
5)

I think the draft described the easy piece, which takes requests from a resource reservation protocol and pushes them to 6P. I’m missing the more difficult piece, the interaction with the RSVP protocol. Does the RSVP propagation wait at each hop for the reservation at 6P layer to be complete? Is there a 3p hase commit, like the actually booking comes with a return PATH message? What are the error cases and roll back techniques?

[SA] For "00" version, we just assume that RSVP is out-of-scope (due to the uncertainty in the selection of distributed and centralized approaches for resource reservation protocol). Based on the discussion yesterday, it is clear
to me that we need to focus on the distributed approach, and come up with a lightweight adoption of RSVP for LLNs for handling resource reservation without any central controller."

Cheers,

Pascal

From: 6tisch [mailto:[e-mail]] On Behalf Of Satish Anamalamudi (Satish Anamalamudi)
Sent: vendredi 10 juin 2016 11:22
To: Xavi Vilajosana Guillén <[e-mail]<mailto:[e-mail]>>; S.V.R.Anand <[e-mail]<mailto:[e-mail]>>
Cc: Lijo Thomas <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [6tisch] 答复: T: FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt

Hello Xavi,

alternately, we can take SDN approach whereby we can think of a virtual RSVP
protocol instance running in the PCE instead of on the motes. The PCE can
install the resources over CoAP messages. When track timeout is detected by the PCE
via a network monitoring entity NME, it can take back the resources by sending
teardown message to the nodes.  This way the resource reservation protocol overhead has been
off-loaded to PCE.

With Regards,
Satish.
发件人: Xavi Vilajosana Guillén [mailto:[e-mail]]
发送时间: 2016年6月10日 16:15
收件人: S.V.R.Anand
抄送: Satish Anamalamudi (Satish Anamalamudi); Lijo Thomas; [e-mail]<mailto:[e-mail]>
主题: Re: [6tisch] T: FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt

Hi,

in protocols such as RSVP the tracks are maintained by refresh message and a node timeout. Every time a refresh message is relayed through the track the freshness counter is updated. If a track timeout is detected in a node the node releases the resources. Nodes send periodic refreshing to maintain tracks in a best effort way. Any node can sent at any time a tear down message to terminate the track.

I think this idea can be extended and applied here.

regards,
Xavi


2016-06-09 20:35 GMT+02:00 S.V.R.Anand <[e-mail]<mailto:[e-mail]>>:
Hi Lijo,

Your question on the lifetime of a TrackID can be split into two sub-questions.

One relates to the time itself, and the other is the track termination procedure. A
short answer to the first is, it is application specific. The second is more
involved as there are several ways of terminating a track.

(i) One of the P2P end nodes can signal the PCE via a teardown message so that
PCE can release the chunks allocated to the intermediate nodes during the
resource reservation. The flip side of this seemingly graceful way is that if
there are plenty of short-lived tracks in the network, then the network will be
loaded with many control messages, not desirable in LLNs (ii) PCE automatically
reclaim the chunks based on the degree of idleness based on the information
obtained from NME. There is a trade-off here too.

Hope the above addresses your question.

Anand



On Thursday 09 June 2016 06:20 PM, Satish Anamalamudi (Satish Anamalamudi) wrote:
> Hello Lijo, > > Thank you for your questions. > > Main role of TrackID : > 1. Track forwarding is very similar to IP forwarding where each and every hop is related to local Track-ID (like IP address) to switch the tracks towards Destination. Later, cells are used as implicit labels to switch it to next-hop cells of associated Track-ID. > 2. To identify the associated L2-bundles at each and every hop to forward the data to next-hop neighbors and dynamically adapt the cells in associated L2-bundles. > > As of now I don't have exact answer for "Life time of a TrackID". I will message to you very soon once I know the answer for it. > > With Regards, > Satish.  > -----®öŸö----- > Ñöº: Lijo Thomas [mailto:[e-mail]] > Ñ öô: 2016t6 9å 20:19 > 6öº: Satish Anamalamudi (Satish Anamalamudi); [e-mail]<mailto:[e-mail]> > ;˜: RE: [6tisch] FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt > > Hi Satish, > > I have a couple of queries regarding the SF1 draft . > > 1. In the draft it says a TrackID is generated for each 1 hop communication. > I had a feeling that the TrackID remains the same for an end-to-end packet flow.  Please correct me if I am wrong > > 2. Life time of a TrackID > > Hope these are relevant to your draft  : > > Thanks & Regards, > Lijo Thomas > > > -----Original Message----- > From: 6tisch [mailto:[e-mail]] On Behalf Of Satish Anamalamudi (Satish Anamalamudi) > Sent: 06 June 2016 15:31 > To: [e-mail]<mailto:[e-mail]> > Subject: [6tisch] FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt > > Hello everyone, > > A new draft is proposed for hop-by-hop scheduling through Scheduling Function One(SF1). Your comments are highly appreciated. > > With Regards, > Satish. > >> -----Original Message----- >> From: I-D-Announce [mailto:[e-mail]] On Behalf Of >> [e-mail]<mailto:[e-mail]> >> Sent: 2016t6 6å 17:54 >> To: [e-mail]<mailto:[e-mail]> >> Subject: I-D Action: draft-satish-6tisch-6top-sf1-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >>         Title           : Scheduling Function One (SF1) for hop-by-hop >> Scheduling in 6tisch Networks >>         Authors         : Satish Anamalamudi >>                           Mingui Zhang >>                           Charles E. Perkins >>                           S.V.R Anand >>     Filename        : draft-satish-6tisch-6top-sf1-00.txt >>     Pages           : 10 >>     Date            : 2016-06-06 >> >> Abstract: >>    This document defines a 6top Scheduling Function called "Scheduling >>    Function One" (SF1) to schedule end-to-end dedicated L2-bundles hop- >>    by-hop for each instance.  In addition, SF1 dynamically adapts the >>    number of reserved cells in scheduled end-to-end L2-bundles of an >>    ongoing instance through a Resource Reservation Protocol.  SF1 uses >>    the 6P signaling messages with a TrackID to add/delete cells in end- >>    to-end L2-bundles of each instance. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-satish-6tisch-6top-sf1/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-satish-6tisch-6top-sf1-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org<http://tools.ietf.org>. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> [e-mail]<mailto:[e-mail]> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > 6tisch mailing list > [e-mail]<mailto:[e-mail]> > https://www.ietf.org/mailman/listinfo/6tisch > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > 6tisch mailing list > [e-mail]<mailto:[e-mail]> > https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch



--
Dr. Xavier Vilajosana Guillén­
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya­

[phone]| [e-mail]<mailto:[e-mail]>­ | Skype­: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)

[http://wine.rdi.uoc.edu/wp-content/uploads/2016/01/wine_LOGO_small2-e1453363995864.png]

­