Re: [Dcpel] Purpose of a diffserv control plane

Paulo Mendes <mendes@docomolab-euro.com> Mon, 21 November 2005 09:36 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee86L-0007sd-BG; Mon, 21 Nov 2005 04:36:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee86J-0007sV-29 for dcpel@megatron.ietf.org; Mon, 21 Nov 2005 04:36:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16397 for <dcpel@ietf.org>; Mon, 21 Nov 2005 04:36:01 -0500 (EST)
Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ee8Oj-0004yz-2X for dcpel@ietf.org; Mon, 21 Nov 2005 04:55:41 -0500
Received: from 172.27.10.3 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Mon, 21 Nov 2005 10:36:00 +0100
Received: from [172.27.100.47] ([172.27.100.47]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 21 Nov 2005 10:36:00 +0100
Message-ID: <438196C6.5000204@docomolab-euro.com>
Date: Mon, 21 Nov 2005 10:43:34 +0100
From: Paulo Mendes <mendes@docomolab-euro.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pulliam, Jeffrey S" <jeffrey.s.pulliam@lmco.com>
Subject: Re: [Dcpel] Purpose of a diffserv control plane
References: <CF127EA649E2804ABF97FD457A9FD4B308AE7B01@emss01m10.us.lmco.com>
In-Reply-To: <CF127EA649E2804ABF97FD457A9FD4B308AE7B01@emss01m10.us.lmco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2005 09:36:00.0702 (UTC) FILETIME=[FBC21DE0:01C5EE7E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f
Content-Transfer-Encoding: 7bit
Cc: dcpel@ietf.org
X-BeenThere: dcpel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

Hi Jeffrey

comments inline..

Pulliam, Jeffrey S wrote:

>Pablo
>
>Good start on a requirements document.  I suspect we will discuss
>requirements a lot before this is done.  A few comments:
>
>I generally agree with your assumptions in the ID you and Kathie
>drafted, as well as the core requirements.  There are points of concern
>I would like to bring up.
>
>- Signaling Protocol Translations
>
>I fully concur with use of signaling protocols developed in other
>efforts in the IETF.  In addition to NSIS, we need to recognize
>RSVP/ARSVP as an appropriate signaling protocol for use in a DiffServ
>Control Plane.  Further, we should give some thought to the possibility
>that different domains will use different signaling protocols, and that
>the interdomain control plane function should allow for / provide for
>translation between signaling protocols.  
>  
>
[Paulo] It is not the role of the requirements document to say what 
protocols should be used. IMO, different domain may use different 
protocols, if they fulfill the system requirements. The only protocol 
that different domain must have in common, it the inter-domain 
signalling protocol, which, as you say, must hide the intra-domain 
specialties, as said in section 5.3 of the document.

>Your draft has the following language that heads in this direction
>
>***SNIP**** from the requirements draft
>4.0 Assumptions
>...
>   o  Existing protocols, such as HTTP, COPS, SNMP, NETCONF, or the
>      NSIS protocol suite.  
>...
>
>5.2.  Intra-domain Control
>   o  There must be a common intra-domain interface, allowing network
>      elements to coordinate their actions, independently of the degree
>      of control distribution.  This interface can by defined by
>      messages sent over protocols such as COPS, SNMP, or the NSIS
>      protocol suite.
>***SNIP***
>
>I recommend including RSVP/ARSVP in both lists of protocols.  Also
>suggest that specification of use of a specific signaling protocol
>should be constrained to a single domain, or a single relationship
>between two distinct domains.  A domain should be free, and the control
>plane should enable a domain to interact with other domains over
>multiple signaling protocols, if necessary.  But primarily, I don't want
>to leave out the RSVP/ARSVP protocol suite, and think we need to
>leverage the work currently underway focused on effecting precedence and
>pre-emption, as well as security related issues.  
>  
>
[Paulo] I'll add RSVP to the list of protocols that may be analyse 
against the requirements.

>You identify two roles a domain can play, provider, and customer.  What
>do you think about subdividing the provider role into access provider,
>and transit provider?  One example of a transit provider is in the
>assumptions in your draft
>  
>
[Paulo] I the document I don't mention two, but three roles: customer, 
provider, and both, this is customer-provider. In the case of access and 
transit network, I'll say that an access network can be a customer or a 
provider, while a transit network is a customer-provider network.

>***SNIP*** from the requirements draft
>
>4.  Assumptions
>...
>   o  For inter-domain considerations, although not all networks will be
>
>      DiffServ, all will interact based on the same inter-domain control
>      interface.  For instance, backbone networks may be over-
>      provisioned, but they will still offer and negotiate QoS
>      agreements with its neighbors.
>...
>***SNIP***
>
>The overprovisioned backbone provider will communicate using the
>DiffServ Control plane mechanisms, but will map all traffic to one of
>it's offered services, and provide signaled, unimpeded, albeit
>overprovisioned transit through it's domain as it's contribution to end
>to end service delivery.  The fact that it is an overprovisioned network
>will be invisible to the neighboring interconnected diffserv domains.
>Which is ok if that transit meets the allocated portion of the
>end-to-end spec for the offered diffserv service? 
>  
>
[Paulo] So, you agree with what is currently written in the ID document, 
right?

>Media Dependent Requirements - 
>
>So another recurring theme that seems to be in the requirements draft is
>that different domain types will have different requirements that are
>media dependent.  In the draft, you mention mobile networks in a few
>places, and the need to support mobile networks.  It might be useful in
>the requirements draft to isolate requirements that emerge that are
>specific to mobile networks.  Another network type that would be useful
>to have addressed in the draft is satellite networks.  A satellite
>network can provide diffserv enabled services, but in the case of the
>geostationary satellite, will impact the end to end guarantee of
>latency.  A useful requirement that is somewhat specific to satellite
>networks is that when a network domain in unable to deliver services
>within the spec for the end to end service, that it make an offer of
>services to be delivered within a modified spec.  For example, in a case
>where end to end latency requirement is under 150ms, a geostationary
>satellite network asked to participate might offer services with an
>additional 260 - 300 ms latency, resulting in an end to end service with
>410-460ms latency.
>
>I feel the need for a picture, and will take a swing at it and send when
>complete. 
>  
>
[Paulo] The mobility of networks may impact the inter-domain control 
only. So, I can create a sub-section to describe the requirements for 
moving networks in the inter-domain control section. However, I would 
like to generalize this to include not only moving networks but all kind 
of discontinuity. This before the mobility of network can be seen as a 
particular example of an environment in which networks may be mostly 
disconnected. This may not be the case in the backbone of the Internet, 
but may be the case of edge networks.

In the case of satellite networks, I think that we can also generalize 
this situation, since any network may not be able to fulfill some e2e 
QoS requirements. The fact that a network may be allowed to offer 
services, may give to a customer some indication about what provider to 
select. For instance, in the example that you gave, if a customer 
network gets from a satellite provider network an offer of 260 - 300 ms, 
and a offer of 150 - 200 ms from another neighbour, it might decide to 
negotiate an agreement with the second provider and not with the 
satellite network. If this is what you are thinking about, I think that 
the following requirement is suitable: "The inter-domain interface must 
allow network domains to offer, request/negotiate, and monitor 
agreements/SLSs.". I can provide an example of this announcements and 
negotiations.

>More Below 
>
>Jeff
>
>  
>
> *** Some part of my original mail removed ***
>
>
>[[jeff]] So I support development of an information model for diffserv
>control plane information, and this is certainly a part of the language
>in point 1.  There are some higher order concepts that we should attack
>in route to the development of the information model, which includes a
>list and definition of what should be in the information model, a list
>of verbs that contains the actions performed by the control plane.
>
[Paulo] IMO the inclusion of requirements specific for this information 
model will be beneficial. I'll create a sub-section dedicated to 
identify the requirements of such information model.

>  
>  
>
>>2) where to implement the requests: in the I-D we refer as assumption
>>the exiting of network-wide agents (agents with network-wide
>>functionality) and local-agents (such as agents placed at the edges of
>>    
>>
>a
>  
>
>>network). These are the places to configure due to a set of requests.
>>How to configure them depends on what functionalities we decide to
>>    
>>
>place
>  
>
>>in these two types of control elements, and on a needed intra-domain
>>interface.
>>    
>>
>
>[[jeff]] So this is a little different that Roberts point 2 - but is
>important.  My point, which Robert phrased fairly well, was that the
>control plane needs to have logic for deciding how to implement the
>request within the domain, and where necessary, to request services from
>other domains.  This is roughly equivalent to a routing IGP and EGP.
>
>I will be able to support a model for the control plane that is agent
>based, that provides for implementation flexibility.
>  
>
[Paulo] My only concern at this point was to work a little on the type 
of network elements that we'll need to consider. I didn't want to write 
requirements to rule the behaviour of such agents. But I might say that 
the network-wide agent (a central or distributed element) may be 
responsible for the inter-domain control and making the needed interface 
to the local-agents, which may be responsible for the intra-domain 
control. For instance we can see the inter-domain responsibilities of a 
network-wide agent as a 'broker' to negotiate agreements between 
networks. And we can also see local-agents placed, implementing 
measurement-based or flow-based (supported by path-coupled signalling) 
admission control mechanisms, and allocating the needed resources to the 
requested PDB.

>  
>
>  
>
>>4) the interaction with AAA is also referred in the I-D, in which an
>>initial reference to authentication and trust is made, and in which is
>>also said that "Authentication may be a part of the control plane, or
>>may be an accessible external functionality". However, lots of work in
>>the what concerns requirements still needs to be done.
>>    
>>
>[[jeff]] In particular on issues of trust, and use of authentication
>services provided external to the diffserv control plane.  I don't think
>we want to create our own AAA function unless necessary, and in the case
>of authentication and authorization, we should allow for use of whatever
>the domain feels is necessary.  
>  
>
[Paulo] Agree. This is why on requirements says that : "Authentication 
may be a part of the control plane, or may be an accessible external 
functionality." Is this what you meant?

>  
>
>>5) The need for a protocol to adjust the PDBs is also mentioned in
>>section 5.4 of the I-D. That section provides a brief example of how a
>>mechanism to implement the decision in the forwarding plane of a
>>DiffServ domain may be done. Nevertheless, as said, we should look at
>>existing protocols that may fit the needed requirements, of part of it
>>(in the latter case, DCPEL may suggest extensions, modifications, etc,
>>to those protocols). For instance, we could analyze how the NSIS
>>proposals could be used for this propose, in order to signal several
>>network elements in the data path (path formed by all routers crossed
>>    
>>
>by
>  
>
>>data packets) from one ingress to one egress point. To implement the
>>mentioned inter-domain interface, IMO we need signaling decoupled from
>>the data path. And since the elements involved in the signaling
>>    
>>
>process
>  
>
>>are only the initiator (one element in one domain) and the destination
>>(one element in a neighbor domain), it is not clear if all the
>>functionalities provided by NTLP are needed. So, needs to be analysed
>>how can current proposals for off-path NSIS signalling fit some of the
>>requirements of the DCPEL (intra or inter-domain). I'm saying this
>>    
>>
>since
>  
>
>>DCPEL aims, IMHO, to analyse network-to-network behaviors (traffic
>>oriented!), and not end-to-end behaviors (flow oriented!).
>>    
>>
>[[jeff]] So I was in agreement until the last - the control plane either
>needs to be able to translate a flow oriented requirement into a traffic
>oriented policy, or something else does.  So I expect we will want to
>discuss this a bit.
>  
>
[Paulo] I agree that this needs more work, so at least I'm opened to 
discuss this. IMO, DCPEL will give DiffServ networks capability to 
dynamically control they internal resources, and to be able to interact 
with they neighbours. I think that the intra-domain and the inter-domain 
control are tight together, since changes inside a network may impact 
the inter-domain relationship, and vice-versa.
So, within DCPEL what we have is network-to-network interactions and not 
end-to-end. However, we need then to analyse what type of relationship 
will DCPEL have with end-to-end signalling in oder to target e2e QoS 
assurance. Just to add another though to this issue, maybe in a chain of 
DCPEL networks, the e2e signalling to set resources for a flow may be 
simpler or faster, since what we may only need is a mechanism to check 
PDBs in each network. For instance we may use QoS-NSLP to signal only 
ingress points of DCPEL networks in order to trigger the needed PDB 
allocation.

>  
>
>>So, answering to your questions. IMO, DCPEL should aim to look at all
>>these issues, since they are all needed to define the control elements
>>of a DiffServ domain. Once more, it is up to us to schedule such work
>>after a good understanding of assumptions and requirements.
>>
>>IMO, we need to discuss the problem statement and scope, the list of
>>assumptions and the requirements for th e DCPEL. This will allow us to
>>clearly define a charter with a coherent work priority.
>>    
>>
>[[jeff]] Agree - 
>  
>
Paulo

_______________________________________________
Dcpel mailing list
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel