Hi Xavi,
Yes, I agree. For LLNs, I suppose we might need to adapt RSVP suitably. In
my mail I tried to weigh the options with RSVP in mind.
Anand
On Friday 10 June 2016 01:45 PM, Xavi Vilajosana Guillén wrote:
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://xvilajosana.org>
http://wine.rdi.uoc.edu/
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
