Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 20 June 2018 14:54 UTC
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991E0130F08; Wed, 20 Jun 2018 07:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDmhI7BR9h_3; Wed, 20 Jun 2018 07:54:02 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAC0130ED6; Wed, 20 Jun 2018 07:54:01 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id v131-v6so47333wma.1; Wed, 20 Jun 2018 07:54:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZJI+MEM1pooQK9gGB1/f0S1sXYrlUPzNA/mMZ7PFl20=; b=krMLzysEOCDMZIdVpjby60XspQLikY+miJJ2dCS1NfHWLR5MQcQEhntWHuwB7ZdvgE RN1JqSUJ+IZinyRN3PLdF4RxlyjMmom6F/EdCOh8l/Qh5Z9/tMqBt5wvL07QiS98z60s eeCIzsrXijceuqp/PZMFuk+nokw9s9ewUcyWAnZdLJ67X6mWY3ca0u6dVXuwGsIb6tpq Onb67NpVw8KvjnMKOdseG6Yyco+lXyeVAWvlQ6u/hSSHCyDKRijiCsJdGnQRgevUckuR MoTmGJyyYqzYDBFZ647mT2EFA4jyckMmbFhK/LCX6+3bfInJL8IygkrR1SdTQkdgSAq+ 23Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ZJI+MEM1pooQK9gGB1/f0S1sXYrlUPzNA/mMZ7PFl20=; b=fMDm7JMBYecog60Ui3SJ7owAXuai9FbWZBiqqkrJpxUJW9fSU/7ZG2mgJ+YfEGTRNX /rJ+IaeUZaSU7wXCLVOavQIXrpEAOQJzkDZQkofoizBswiCCjw8DMqspTK4lXcr3H+1C JSOcV1D/mjaxjesR7uZZoWMS9DTMMrkhpUgJl7GpTTh22lVLRSMm34UKchy0oEGBrqQ2 ijEIjb35L4qddtBTox8bkd2z7nS3nnHFwdntNN7UNF12WeK2JvBIA0D+3hX604WdF9bh PGgWb4KUoSsqBV6x4QcK0+MBYD8QylYL3vTjwVsxMRpD5h27WzNjlh8zd51hyi81gDok 1Gpg==
X-Gm-Message-State: APt69E2sD/4NOQr1izzTDjqTkaTbEqkzJyKaViCMay05FwSL4gfqiNbG 3qspctI2TqX0FBgD5rZFY0//aKEHoV9X+DQAn/o=
X-Google-Smtp-Source: ADUXVKJYvFXPg1Z234Lqqda8V/BRb1aG//cJ73MsNZqqBkxoU8aXQ+0OqhjHmkca+zw+3NiyZ60v8hzs3Gk8Io3yhdk=
X-Received: by 2002:a1c:9c0b:: with SMTP id f11-v6mr1992187wme.148.1529506440271; Wed, 20 Jun 2018 07:54:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:fc84:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 07:53:59 -0700 (PDT)
Reply-To: sarikaya@ieee.org
In-Reply-To: <1529505221125.58728@cisco.com>
References: <CAHx=1M5MFsR6xBvetXEgcjsLJ8rmuLLBWMf9iXSQDguTwMh4Gg@mail.gmail.com> <CAPDqMeonj=E8B9MT3_9zBSzQGgkiqEoMt3a+TX+68OFDeusC7Q@mail.gmail.com> <CAHx=1M7BsPwBbO7UwcCdZfQu4XoiCvLjiuh3pAO_-DV_s_TyBg@mail.gmail.com> <CAPDqMeomQdDEb0uh1fS2vxvDJzg3+47m-bhz5Ah_O=ay5LFOhQ@mail.gmail.com> <CAHx=1M5DizvHPxSxxruS9iJA177GOWuQvv+tOWBwT+QXTZt3GA@mail.gmail.com> <CAC8QAceg0-_41iSC6eBun+uNZ+UA1kn1euf1yWvZ4byRRGOu9w@mail.gmail.com> <1529505221125.58728@cisco.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Wed, 20 Jun 2018 09:53:59 -0500
Message-ID: <CAC8QAcd5_P4=ESzKJFXFURtmW3WXE6haVXm_jO9QB=3i8H-4mg@mail.gmail.com>
To: "Giovanna Carofiglio (gcarofig)" <gcarofig@cisco.com>
Cc: Luca Muscariello <luca.muscariello@gmail.com>, Internet Area <int-area@ietf.org>, "Luca Muscariello (lumuscar)" <lumuscar@cisco.com>, Tom Herbert <tom@quantonium.net>, dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000de08b056f13f8cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/SeXBHpSkWvGOPGq2VOQRnayY5eQ>
Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2018 14:54:05 -0000
On Wed, Jun 20, 2018 at 9:33 AM, Giovanna Carofiglio (gcarofig) < gcarofig@cisco.com> wrote: > This draft is about hICN and discusses various deployment options with > associated pros and cons, without supporting one specifically. Clearly, > depending on application requirements, on network constraints, on phase of > deployment/transition etc. one option may be preferrable over another one > (and different ones may coexist). > > > One of the described deployment options also discusses combination of hICN > and SRv6, without opposing one approach to the other, rather exploiting in > the combination the advantages of both ones. > > > I don't understand. SRv6 is tunneling technique while hICN is talking about anchoress mobility. Did I get something wrong? Behcet > Giovanna > ------------------------------ > *From:* Int-area <int-area-bounces@ietf.org> on behalf of Behcet Sarikaya > <sarikaya2012@gmail.com> > *Sent:* Wednesday, June 20, 2018 4:18 PM > *To:* Luca Muscariello > *Cc:* Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm > *Subject:* Re: [Int-area] [DMM] New draft posted: Anchorless mobility > management through hICN (hICN-AMM): Deployment options > > > > On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello < > luca.muscariello@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 <tom@quantonium.net> wrote: >> >>> On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello >>> <luca.muscariello@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 <tom@quantonium.net> >>> wrote: >>> >> >>> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >>> >> <luca.muscariello@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-mobilit >>> y-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 >>> >> > dmm@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/dmm >>> >> > >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >
- Re: [Int-area] [DMM] New draft posted: Anchorless… Tom Herbert
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Behcet Sarikaya
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Tom Herbert
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Tom Herbert
- Re: [Int-area] [DMM] New draft posted: Anchorless… Behcet Sarikaya
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Giovanna Carofiglio (gcarofig)
- Re: [Int-area] [DMM] New draft posted: Anchorless… Behcet Sarikaya
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Giovanna Carofiglio (gcarofig)
- Re: [Int-area] [DMM] New draft posted: Anchorless… Tom Herbert
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Luca Muscariello
- Re: [Int-area] [DMM] New draft posted: Anchorless… Tom Herbert