On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < luca.muscarie...@gmail.com> wrote:
> I wonder whether this conversation should happen in the intarea wg mailing > list > as the main draft was posted there in the first place. I don't know if > cross posting is welcome > but I take the risk. > > Going back to the question, the transport changes are related to the > request/reply semantic > of the architecture. The two distinct forwarding paths described in the > draft take care > of forwarding requests or replies.This ends up in the transport layer as a > unidirectional > channel to recv data or snd data. The replies carry data originating from > a transport end-point (snd buffer) > that binds to an identifier which is location independent, an IPv6 number > which is not a locator. > > The forwarding path of the requests is very close to unmodified IPv6 with > the DST address carrying the identifier. > If you check in the draft an hICN node does one additional lookup in a > local cache though. But you can ignore that > for now for sake of clarity. What is important is the address rewrite > operation made on the SRC address > of the request. A copy of the request is stored in the local cache and the > locator of the output interface is written in the > SRC address before transmission. This is used by an upstream hICN or the > final end-point to know the locator that > will be used to reply. > > Replies coming from the snd end-point are label swapped but not like MPLS. > The label is the identifier itself that is stored in the SRC address of > the reply, > whereas the DST address is a locator. In this forwarding path a lookup is > made in the local cache to > find a request (one or many) and the associated locator (one or many) that > matches the identifier. > The DST addr field of the replies is rewritten with the locator(s) just > obtained from the lookup. > This is how the reply is forwarded to the end-points that issued requests > for this identifier. > > For the replies there is no FIB lookup on the identifier (as it is in the > SRC addr field). > There can be a lookup in the FIB on the locator stored in the DST of the > reply to > reach back the previous hICN node or eventually the original end-point. > > > > Hi, My humble question is: are you supporting SRv6 or hICN? Regards Behcet > > > > > On Wed, Jun 20, 2018 at 12:30 AM Tom Herbert <t...@quantonium.net> wrote: > >> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >> <luca.muscarie...@gmail.com> wrote: >> > The paragraph you reported is from the draft that describes hICN to >> enable >> > several use cases. >> > Mobility is one of those, not the only one. >> > To clarify, the draft on hICN mobility deployment options focuses on >> the 5G >> > service based architecture. >> > >> > You may be asking >> > 1) is it possible to get all the features provided by hICN w/o updates >> to >> > the transport layer? >> > 2) is changing the transport protocol unnecessary difficult to enable >> all >> > the use cases mentioned in the draft? >> > >> Sorry, but I'm still missing something fundamental here. AFAICT, the >> idea of hICN is to put routes in the local routing table and use >> existing forwarding and routing to forward packets to mobile nodes. So >> if a node changes location, then the routing tables need to be >> updated. Effectively this is a bunch of host routes that need to be >> maintained. At least this is what I gather from the draft: >> >> "hICN network layer is about using the IPv6 FIB to determine a next >> hop router to forward requests or using a local packet cache to >> determine if an incoming request can be satisfied locally." >> >> Is this correct? If it is, then I sort of understand how hICN could be >> used for mobility or virtualization without network overlays, but then >> I'm completely lost as to why this would require any changes in the >> transport layer. >> >> Tom >> >> >> >> >> >> > IMO, the answers are no for both. >> > >> > Luca >> > >> > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert <t...@quantonium.net> wrote: >> >> >> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> >> <luca.muscarie...@gmail.com> wrote: >> >> > Hi all, >> >> > >> >> > the draft below has been posted and describes deployments options for >> >> > anchorless mobility management by using >> >> > the hicn network architecture that implements icn semantics in IPv6 >> >> > networks. >> >> > >> >> > >> >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn- >> mobility-deployment-options >> >> > >> >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> >> > >> >> > A background document has been posted to the internet area WG and >> >> > reported >> >> > here for your convenience. >> >> > The core principle behind hicn and mobility management is that data >> >> > sources >> >> > are named using location independent names >> >> > encoded in IPv6 addresses. The transport service sitting on top of >> the >> >> > hicn >> >> > architecture is not based on usual TCP/UDP sockets >> >> > but on a novel consumer/producer transport service that will be >> >> > described in >> >> > another draft. >> >> >> >> From the draft: "The transport end-point offers two kinds of services >> >> to applications: a producer and a consumer service. The service is >> >> instantiated in the application by opening communication sockets with >> >> an API to perform basic transport service operations: allocation, >> >> initialization, configuration, data transmission and reception." >> >> >> >> This seems like a pretty dramatic rethink of the transport layer just >> >> for the purposes of mobility management. Will there be a way to use >> >> hICN at the network layer with exsiting and unmodified transport >> >> protocols (i.e. can this be done without boiling the ocean)? >> >> >> >> Thanks, >> >> Tom >> >> >> >> >> >> >> >> > The current document and a companion document that will be posted >> soon >> >> > describe the different deployment options >> >> > with special care to the 5G service based architecture. >> >> > Thanks for the comments already received that helped completing this >> -00 >> >> > draft. >> >> > >> >> > Luca >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > dmm mailing list >> >> > d...@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/dmm >> >> > >> > > _______________________________________________ > dmm mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
