Subject: RE: [NSIS] WG requirements draft

From: [email-masked]
Date: Fri, 1 Mar 2002 22:56:00 +0200

Hi Roland & Danny,

> Yes, I agree that we have to define the interfaces for which we are
> developing nsis protocols. But in this context we have also to name
> the entities that talk to each other via these interfaces/protocols. 
> We should consider a wide range of scenarios to find a common 
> denominator for these interfaces.

One think that might be useful in this requirement phase would be to
be thinking in terms of clouds rather than strings.  Clouds being
more like QoS realms (or domains) rather than links.  As what
we are trying to do is abstract resource signaling from resource
reservation, this could be a useful way to try to capture the
requirements.  In this model, interfaces become more abstract
and less literal than if we are thinking about the physical
interfaces between 2 network entitites.

food for thought,
John

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Mar 2002 11:50:32 +0100

Hi John,

> interfaces between 2 network entities.

Good point. I also thought about a more abstract model when 
people wrote about access and core networks, which isn't always
appropriate (what is _the_ core?), so this needs clarification.

Shouldn't we assume the overall Internet architecture as basis?
Therefore, on your proposed abstract level we have interfaces between
a) hosts/end-systems
b) Autonomous Systems/QoS Domains
(Surely, hosts are also part of an AS)
There are different type b) networks: 
- stub (carrying traffic from and to access networks), 
- pure transit (containing no  access networks, thus
  carrying traffic of other ASs), and 
- mixed ASs (having access networks as well as forwarding
  transit traffic)
but I don't think we should make an explicit difference between 
them and assume the last case.

This view leads mainly to a kind of UNI/NNI perspective. However, 
there are many other components within an AS/Domain and thus many 
additional (mainly already existing) signaling protocols within 
a Domain (e.g., COPS, MT<->SGSN/GGSN mobility etc) depending on 
the particular QoS implementation architecture. 

I thought, that work is mainly needed at the interfaces from 
a) <-> b) and b) <-> b), therefore being independent from the
actual underlying QoS architecture. Interface a) <-> b) should 
especially consider mobility and security issues, but it should
be independent of what is the conrete peer within b): a Domain
Manager, an access/edge/boundary router or some kind of proxy.

Are there other requirements which won't fit to this more
abstract model?

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097