Hello Pascal, Thanks a lot for your comments and suggestions. Please, see my reply with [SA].
With Regards, Satish 发件人: Pascal Thubert (pthubert) [mailto:[email protected]] 发送时间: 2016年6月10日 19:42 收件人: Satish Anamalamudi (Satish Anamalamudi) 抄送: [email protected] 主题: 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:[email protected]] On Behalf Of Satish Anamalamudi (Satish Anamalamudi) Sent: vendredi 10 juin 2016 11:22 To: Xavi Vilajosana Guillén <[email protected]<mailto:[email protected]>>; S.V.R.Anand <[email protected]<mailto:[email protected]>> Cc: Lijo Thomas <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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:[email protected]] 发送时间: 2016年6月10日 16:15 收件人: S.V.R.Anand 抄送: Satish Anamalamudi (Satish Anamalamudi); Lijo Thomas; [email protected]<mailto:[email protected]> 主题: 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 <[email protected]<mailto:[email protected]>>: 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:[email protected]] > Ñ öô: 2016t6 9å > 20:19 > 6öº: Satish Anamalamudi (Satish Anamalamudi); > [email protected]<mailto:[email protected]> > ;˜: 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:[email protected]] On Behalf Of Satish Anamalamudi > (Satish Anamalamudi) > Sent: 06 June 2016 15:31 > To: > [email protected]<mailto:[email protected]> > 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:[email protected]] On Behalf Of >> > [email protected]<mailto:[email protected]> >> Sent: 2016t6 6å > 17:54 >> To: [email protected]<mailto:[email protected]> >> 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 > >> [email protected]<mailto:[email protected]> >> > 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 > > [email protected]<mailto:[email protected]> > > 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 > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> 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 +34 646 633 681| [email protected]<mailto:[email protected]> | 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]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
