Subject: [icnrg] ICN

From: [email-masked]
Date: Sat, 2 Feb 2013 16:33:03 +0530 (IST)

Hi,
 I was beginning to think about the management items in the research
challenges section...Before that i would like to get grips on the
converse, ie what are the items to be managed.
 A aimple version of ICN could be directory based ids to route requests to
and caching of data.
 Thought why not let loose a bit, and consider ICN as a compeltely
different abstractino while drawing on analoges to HCN. Managing the
below scenarios would involve two aspects,
   The ICN Network Components
   Mapping between ICN Network components to the real network.
   Maybe this is more of an Intelligence Centric Network than an
Information Centric Network...but still here it is....

   In the host centric networks we have Device Management, EMSes, NMSes
and OSSes, all of which together enable network operations.   It needs
to consider if this kind of an architecture for network operations hold
in the case of and ICN.  Host centric networks is not going to be
replaced by ICN in the near future.  ICN must run on top of a host
centric network though it is debatable how of much of intelligence
would stay at the network centric layer.
Manageability of an Information Node.
	Before we consider the manageability of the information node,  we need to
consider the architecture of the information node in itself, which would
give a basis on what it is that is to be managed.  We could perhaps take
inspiration from the host centric network itself.
	The information itself could be considered as an analog to bits and bytes
and the node a kind of a “processor” of the information.
Are there different types of Information Nodes?   The simplest ones would
be those Information Nodes that  do nothing but source information.   The
analogue for these in the host centric network would be end user devices,
PCs, Mobiles, T.Vs…This means that  an ICN could have analogues to
switching and routing devices that actually process information.   This
also means that we could fathom a scenario wherein there is an entire ICN
within a single host centric node, though that is not the most general
case, allowance must be made in the architecture for the same.  Read with
the above we cannot, in the more general case,  rule out a situation where
an information node that processes information is spread across several 
host centric nodes. This would correspond to a distributed network or a
cloud.
	Continuing with the analogy, we look at what is a link in the case of an
ICN? For this we need to consider, what is transport in the case of an
Information.  In a host centric networks, the mapping of bits and bytes 
to the physical coordinates changes. What could be the analogy to
physical coordinates in the case of an information?  The fundamental
aspect in a transport (across a dumb pipe) is that the data itself
dosen’t change.   Here then the information entity itself dosen’t change
in the case of a “dumb” pipe transport.   What then could change?  Here
we could consider an information architecture consisting of information
and the context.  That is, the same information can be interpreted in
different contexts.   Transport then in the case of ICN could be
considered as moving the information from one context to the other. A
“dumb” pipe here would be a relative more active processor that changes
the context associated with an information chunk.
	Then we come to aggregation in an ICN.  For this we first look at what is
a port in the case of an information node, for aggregation in an host
centric network takes place across several ports.  We could view this as
ports being transferred to a different bits and bytes in the most general
case.  Let us assume that the operation that switches context and
information chunks is commutative for now.
 	If an ICN link serves to simply change context from one context (port)
to the other (port across the link) a node encapsulates decision logic
on which context switching processor to apply to a given information
chunk.
 	This leads us to a notion of capacity of a port.   This translates to
viewing information “in its larger context” which is precisely what this
document is all about.
	We have ports of varying types in an host centric node.  At least two
ways in which these types differ are a)the capacity and b)the framing.  
We have seen capacity earlier.  What is framing?   In the host centric
network, framing is adding additional bits and bytes that allows
transport and identification of the goal of the transport at the other
end.  Framing therefore translates to add additional information to the
core information that identifies the final context with which that
information is to be viewed,  which may require a series of context
switches in between, aggregation, de-aggregation as mentioned earlier,
 	One likely impedance question between Host Centric and ICN is that while
a host centric network is responsible (at each layer that is) to
transport bits faithfully, could we consider allowing information
modification (other than that brought in by framing) in an ICN. 
Distributed computing is perhaps,  nothing but the region of
intersection between ICN and HCN…

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Dirk Kutscher <[email-masked]>
Date: Sun, 10 Feb 2013 16:48:38 +0000

Hi Sitaraman,

Thanks for the input.

I believe that there are two aspects to this: 1) management of ICNs and 2) ICN-based network management.

>From a research perspective, applying typical FCAPS management to ICN might not be that challenging -- but it is surely important for building and operating networks.

ICN-based network management would be a challenge in a strict ICN model, I believe, because you want to manage nodes and actuate them in the end.

Best regards,
Dirk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Samstag, 2. Februar 2013 12:03
> To: [email-masked]; Dirk Kutscher
> Subject: ICN
> 
> Hi,
> challenges section...Before that i would like to get grips on the converse, ie
> what are the items to be managed.
>  A aimple version of ICN could be directory based ids to route requests to and
> caching of data.
>  Thought why not let loose a bit, and consider ICN as a compeltely different
> abstractino while drawing on analoges to HCN. Managing the below scenarios
> would involve two aspects,
>    Maybe this is more of an Intelligence Centric Network than an Information
> Centric Network...but still here it is....
> 
> to consider if this kind of an architecture for network operations hold in the
> case of and ICN.  Host centric networks is not going to be replaced by ICN in
> the near future.  ICN must run on top of a host centric network though it is
> debatable how of much of intelligence would stay at the network centric
> layer.
> 	Before we consider the manageability of the information node,  we
> need to consider the architecture of the information node in itself, which
> would give a basis on what it is that is to be managed.  We could perhaps take
> 	The information itself could be considered as an analog to bits and
> bytes and the node a kind of a "processor" of the information.
> PCs, Mobiles, T.Vs...This means that  an ICN could have analogues to
> within a single host centric node, though that is not the most general case,
> allowance must be made in the architecture for the same.  Read with the
> above we cannot, in the more general case,  rule out a situation where an
> information node that processes information is spread across several host
> centric nodes. This would correspond to a distributed network or a cloud.
> Information.  In a host centric networks, the mapping of bits and bytes to the
> physical coordinates changes. What could be the analogy to physical
> coordinates in the case of an information?  The fundamental aspect in a
> transport (across a dumb pipe) is that the data itself
> dosen't change.   Here then the information entity itself dosen't change
> in the case of a "dumb" pipe transport.   What then could change?  Here
> we could consider an information architecture consisting of information and
> the context.  That is, the same information can be interpreted in
> "dumb" pipe here would be a relative more active processor that changes
> 	Then we come to aggregation in an ICN.  For this we first look at what
> is a port in the case of an information node, for aggregation in an host centric
> network takes place across several ports.  We could view this as ports being
> transferred to a different bits and bytes in the most general case.  Let us
> assume that the operation that switches context and information chunks is
> commutative for now.
>  	If an ICN link serves to simply change context from one context
> (port) to the other (port across the link) a node encapsulates decision logic
> on which context switching processor to apply to a given information chunk.
> viewing information "in its larger context" which is precisely what this
> document is all about.
> network, framing is adding additional bits and bytes that allows transport and
> identification of the goal of the transport at the other end.  Framing
> therefore translates to add additional information to the core information
> that identifies the final context with which that information is to be viewed,
> which may require a series of context switches in between, aggregation, de-
> aggregation as mentioned earlier,
>  	One likely impedance question between Host Centric and ICN is that
> while a host centric network is responsible (at each layer that is) to transport
> bits faithfully, could we consider allowing information modification (other
> than that brought in by framing) in an ICN.
> Distributed computing is perhaps,  nothing but the region of intersection
> between ICN and HCN...
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.

---

From: Dirk Trossen <[email-masked]>
Date: Sun, 10 Feb 2013 16:56:24 +0000

Dirk Kutscher <[email-masked]> wrote:

>From a research perspective, applying typical FCAPS management to ICN
>might not be that challenging -- but it is surely important for
>building and operating networks.
>
>ICN-based network management would be a challenge in a strict ICN
>model, I believe, because you want to manage nodes and actuate them in
>the end.

So it would be hard to manage ICN with ICN? Can you elaborate?

Best

Dirk
>different
>Information
>transport and
>intersection
>_______________________________________________
>icnrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/icnrg

---

From: [email-masked]
Date: Mon, 11 Feb 2013 09:31:57 +0530 (IST)

Hi,
  What i have proposed below i felt was a different version of ICN itself
in the first place...it goes beyond just naming....isnt it?
Sitaraman
>> might not be that challenging -- but it is surely important for building
>> and operating networks.
>
> ICN-based network management would be a challenge in a strict ICN model, I
> believe, because you want to manage nodes and actuate them in the end.
>
> Best regards,
> Dirk
>
>
>
>> in the
>> case,
>> to the
>> and

---

From: [email-masked]
Date: Mon, 11 Feb 2013 10:27:10 +0530 (IST)

That is i have considered in the below management (and operations which go
beyond management) from the wider scope of ICN as i have described
below...maybe i should also consider management and operations from the
narrower scope then first?
Sitaraman
>> I believe that there are two aspects to this: 1) management of ICNs and
>> 2)
>> ICN-based network management.
>>
>>> is a port in the case of an information node, for aggregation in an
>>> host
>>> centric
>>> transferred to a different bits and bytes in the most general case.
>>> Let
>>> us