Subject: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application?

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 17 Oct 2008 10:19:00 +0200

Hi,

while re-chartering DIME, could we consider a new application for
Carrier-Grade NAT (CGN) control? CGN has become an important topic
within the IPv4-completion/exhaustion debate - also proven by the
significant number of drafts on this particular topic. Consequently, per
endpoint control of a CGN is an important question to be addressed. 
Please find an abstract of a forthcoming draft below. I'm working on the
full draft, but wanted to get the abstract out asap so that the work can
be considered as part of the new charter.

Thanks, Frank

--

Title

   Diameter Carrier-Grade NAT Control Application

Abstract

   The document will describe the framework, messages and procedures for
   the Diameter Carrier-Grade NAT Control (CGNC) application.  The
Diameter
   CGNC application allows gateways (e.g. Network Access Server (NAS))
to
   interact with Carrier-Grade NAT (CGN) devices. The interaction is to
   establish a context to commonly identify and manage endpoints on 
   gateway and CGN. It is to allow the gateway to control and manage the

   behavior of a CGN on a per-endpoint basis (e.g. control the total
number
   of bindings for a particular endpoint, request the allocation of
   a binding for a particular endpoint). In addition, it allows the CGN 
   to provide information relevant to accounting purposes to the gateway

   (e.g. allocated NAT bindings etc.).
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 17 Oct 2008 19:03:30 +0700

Frank Brockners [[email-masked]] writes:

> Carrier-Grade NAT (CGN) control? 

Sounds reasonable to me.

...

---

From: "David Frascone" <[email-masked]>
Date: Fri, 17 Oct 2008 09:53:06 -0400

Do you think we could have a draft before the meeting?

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 17 Oct 2008 16:13:37 +0200

..will try but am not 100% sure yet. Frank

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Frascone
	Sent: Friday, October 17, 2008 3:53 PM
	To: Frank Brockners (fbrockne)
	Cc: [email-masked]
	Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT
Control Application?

	On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne)
<[email-masked]> wrote:

		Hi,
		
		while re-chartering DIME, could we consider a new
application for
		Carrier-Grade NAT (CGN) control? CGN has become an
important topic
		within the IPv4-completion/exhaustion debate - also
proven by the
		significant number of drafts on this particular topic.
Consequently, per
		endpoint control of a CGN is an important question to be
addressed.
		Please find an abstract of a forthcoming draft below.
I'm working on the
		full draft, but wanted to get the abstract out asap so
that the work can
		be considered as part of the new charter.
		
		Thanks, Frank
		
		--
		
		Title

		Abstract
		
		  The document will describe the framework, messages and
procedures for
		  the Diameter Carrier-Grade NAT Control (CGNC)
application.  The
		Diameter
		  CGNC application allows gateways (e.g. Network Access
Server (NAS))
		to
		  interact with Carrier-Grade NAT (CGN) devices. The
interaction is to
		  establish a context to commonly identify and manage
endpoints on
		  gateway and CGN. It is to allow the gateway to control
and manage the
		
		  behavior of a CGN on a per-endpoint basis (e.g.
control the total
		number
		  of bindings for a particular endpoint, request the
allocation of
		  a binding for a particular endpoint). In addition, it
allows the CGN
		  to provide information relevant to accounting purposes
to the gateway

---

From: Avi Lior <[email-masked]>
Date: Fri, 17 Oct 2008 17:42:13 -0400

David,

I agree with Frank that having such an application is required and now is the time to work on it.

I have been engaged with several wireless operators that are planning to deploy a CGN in the next year.  I have been developing a set of AAA requirements to support such deployements over the past month.

It would be good to develop those as the CGN draft is being progressed.

Avi

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Frascone
Sent: October 17, 2008 9:53 AM
To: Frank Brockners (fbrockne)
Cc: [email-masked]
Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application?

On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks, Frank

--

Title

Abstract

  (e.g. allocated NAT bindings etc.).
_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 20 Oct 2008 22:27:45 +0300

A few things: 
 
* The term CGN refers to the ongoing IPv4/IPv6 transition work, right? If
so, I was not aware that they wanted to use an protocol to request mappings
to be created. Instead, the NAT bindings are created based on the flow of
data traffic.  Am I wrong? 
 
* Other SDOs have done work on using Diameter for creating, maintaining and
deleting NAT bindings already. We should re-use their work to avoid
duplicate coding efforts. The entire idea of using Diameter in that space
essentially comes from the MIDCOM days, see
http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't really a
AAA application as such (since the AAA server is not involved there). 
 
* Is the suggestion to only create a Diameter application for allocating NAT
bindings or also QoS parameters and firewalling functionality? 
 
Ciao
Hannes

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Avi Lior
	Sent: 18 October, 2008 00:42
	To: David Frascone; Frank Brockners (fbrockne)
	Cc: [email-masked]
	Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade
NATControl Application?

	David,
	 
	I agree with Frank that having such an application is required and
now is the time to work on it.
	 
	I have been engaged with several wireless operators that are
planning to deploy a CGN in the next year.  I have been developing a set of
AAA requirements to support such deployements over the past month.
	 
	It would be good to develop those as the CGN draft is being
progressed.
	 
	Avi 

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Frascone
		Sent: October 17, 2008 9:53 AM
		To: Frank Brockners (fbrockne)
		Cc: [email-masked]
		Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade
NAT Control Application?

			Hi,
			
			while re-chartering DIME, could we consider a new
application for
			Carrier-Grade NAT (CGN) control? CGN has become an
important topic
			within the IPv4-completion/exhaustion debate - also
proven by the
			significant number of drafts on this particular
topic. Consequently, per
			endpoint control of a CGN is an important question
to be addressed.
			Please find an abstract of a forthcoming draft
below. I'm working on the
			full draft, but wanted to get the abstract out asap
so that the work can
			be considered as part of the new charter.
			
			Thanks, Frank
			
			--
			
			Title

			Abstract
			
			  The document will describe the framework, messages
and procedures for
			  the Diameter Carrier-Grade NAT Control (CGNC)
application.  The
			Diameter
			  CGNC application allows gateways (e.g. Network
Access Server (NAS))
			to
			  interact with Carrier-Grade NAT (CGN) devices. The
interaction is to
			  establish a context to commonly identify and
manage endpoints on
			  gateway and CGN. It is to allow the gateway to
control and manage the
			
			  behavior of a CGN on a per-endpoint basis (e.g.
control the total
			number
			  of bindings for a particular endpoint, request the
allocation of
			  a binding for a particular endpoint). In addition,
it allows the CGN
			  to provide information relevant to accounting
purposes to the gateway

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 21 Oct 2008 07:50:30 +0700

Hannes Tschofenig [[email-masked]] writes:

...

> Please note that this isn't really a

One thing I've been complaining about for a long time is the tendency for
people to talk about Diameter "servers" that don't actually exist (Diameter
being a P2P protocol).  I suppose that many thought me just a bit too picky
(after all, they're only words & _we_ know what we _mean_ ;-) but this is a
perfect example of sloppy language usage leading to sloppy thinking.  IIRC,
one of the reasons that Diameter was _not_ defined as a client-server
protocol was to support exactly this kind of application...

...

---

From: Avi Lior <[email-masked]>
Date: Tue, 21 Oct 2008 07:50:28 -0400

Hi Hannes,

I belive that the AAA work associated with CGN needs to cover the following:

-Whether the session will be NATed or not.  In all cases that I am aware of the NAT is located at the Gateway such as an HA/LMA for mobility services and for simple IP the first attachement point, the NAS, (ASN-GW in WiMAX, PDSN in 3GPP2)

-The configuration of the CGN for the subscriber.  This inlcudes the number of ports, the binding times etc.  Different users will have different requirements, the AAA can deliver those to the CGN when the user is authenticated.

-Deliver policy to the CGN on what pinholes can be opened and what must not be opened by the mobile.

-Authorize any entity that is requesting to open or close a pinhole etc..

In the past, as you are aware, 3GPP2 had a project call NFCC - Network Firewal Configuration and Control -  That project used AAA for the coniguration and authorization part.  It is very similar to be sure.  That application used the AAA to set policy at the firewall and also authorize creation deletion of firewall pinholes.

THe question is whether we can mix Firewall and CGN?

Regarding QoS, it is possible that QoS will also be configured at the same time and some of the pinholes may be associated with QoS configurations.  But other then that, I think they are seperate beasts.

I think the approach for CGN should be like the QoS.  We develope a set of attributes, and also an CGN applications that uses those attributes.  The set of attributes can be used by folks that want a combined QoS / CGN and Newtwork Access Authentication (NASREQ) application.

________________________________________
From: Hannes Tschofenig [[email-masked]]
Sent: Monday, October 20, 2008 3:27 PM
To: Avi Lior; 'David Frascone'; 'Frank Brockners (fbrockne)'
Cc: [email-masked]
Subject: RE: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application?

A few things:

Ciao
Hannes

        David,

        Avi

                        Hi,

                        Thanks, Frank

                        --

                        Title

                        Abstract

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 21 Oct 2008 14:12:35 +0200

Hannes,

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Monday, October 20, 2008 9:28 PM
> 
> A few things: 
>  
> * The term CGN refers to the ongoing IPv4/IPv6 transition 
> work, right? If so, I was not aware that they wanted to use 
> an protocol to request mappings to be created. Instead, the 
> NAT bindings are created based on the flow of data traffic.  
> Am I wrong? 

...FB: "CGN" refers to a Carrier Grade NAT device as used in
  e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence.
  And I agree that for the general case the bindings would be
  defined by the CGN (taken from external and internal 
  address pools), i.e. typically the binding would not be defined
  by an external entity through an interface. Having
  said that, for certain use cases it might be beneficial to
  also cover the case where you want a specific binding to be
  established. As stated in the abstract, the idea of
  the CGN Control Application it largely to perform per endpoint
  control of the CGN, i.e. 
   - specify the maximum number of bindings per end-point
     (and possibly associated hold-timers)
   - provide resports/stats on the currently allocated
     bindings
   - control parameters of binding(s) (i.e. request a 
     specific external ip-address, ip-address/port,
     ip-address/port-ranges). As a corner case this could 
     allow defintion of a complete binding. 

>  
> * Other SDOs have done work on using Diameter for creating, 
> maintaining and deleting NAT bindings already. We should 
> re-use their work to avoid duplicate coding efforts. The 
> entire idea of using Diameter in that space essentially comes 
> from the MIDCOM days, see 
> http://www.ietf.org/rfc/rfc4097.txt. Please note that this 
> isn't really a AAA application as such (since the AAA server 
> is not involved there).

...FB: We should of course see whether we can leverage work
  which was done in other SDOs. As noted above, creating,
  maintaining and deleting NAT bindings would not be the
  primary objective of the CGN Control Application. This
  is what typical control interfaces to "border gateway
  functions" (like a session border controller) would do.
  Here we'd focus more on the per-endpoint control aspects.

>  
> * Is the suggestion to only create a Diameter application for 
> allocating NAT bindings or also QoS parameters and 
> firewalling functionality? 

...FB: Along the lines of what I stated above, the 
  CGN Control Application would really focus on controlling
  bindings on a per-endpoint basis (i.e. provide a set of 
  focused functions for NAT control). QoS and also specific
  firewall rules are somewhat orthogonal (or complimentary).

Regards, Frank

> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Avi Lior
> 	Subject: Re: [Dime] Dime rechartering: Include 
> Carrier-Grade NATControl Application?
> 	
> 	
> 	David,
> 	 
> 	I agree with Frank that having such an application is 
> required and now is the time to work on it.
> 	 
> 	I have been engaged with several wireless operators 
> that are planning to deploy a CGN in the next year.  I have 
> been developing a set of AAA requirements to support such 
> deployements over the past month.
> 	 
> 		From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Frascone
> 		On Fri, Oct 17, 2008 at 4:19 AM, Frank 
> Brockners (fbrockne) <[email-masked]> wrote:
> 		
> 
> 			Hi,
> 			
> 			Please find an abstract of a 
> forthcoming draft below. I'm working on the

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Oct 2008 14:15:08 -0400

I would want to understand the difference between this and the Gq' application 
that now exists. Just from your words: is it that you are talking about imposing 
static conditions per end point rather than per-session control?

Frank Brockners (fbrockne) wrote:
>> Carrier-Grade NAT Control Application?
>> 		
>>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 22 Oct 2008 18:25:09 +0200

Tom,

TISPAN Gq' includes NAT-binding control capabilities for sessions at the
service-layer (e.g. SIP sessions) - representing services provided by
the SP: Among other things, Gq' allows P-CSCF to request allocation
and/or modification of a binding in BGF for a specific media flow. This
makes BGF an anchor point and natural NAT gateway for service-layer
controlled traffic. Hence, Gq' is focused on controlling individual
bindings for service-level traffic flows.

Different from that, the CGN Control application is intended as a
control interface to the CGN, i.e. a NAT device placed between
subscriber-CPE and the public Internet by a carrier - typically
traversed by all the traffic (deployment dependent minus the traffic
handled by BGFs). As noted earlier, bindings within the CGN would
typically not be created through an external interface (with per-binding
signaling procedures) but be created on the fly within the CGN. A CGN
and a BGF would typically operate in parallel - where CGN would provide
NAT-services for all of the traffic that is not "steered" towards a BGF
by a P-CSCF (or similar). Still, it is desirable to control and monitor
some of the behavior of the CGN on a per end-point (or subscriber)
basis, i.e. restrict the number of bindings per subscriber, pre-set
certain ip-address/port-ranges, report allocated bindings etc. Given
that those rules are typically per subscriber (and won't change
frequently), one could call this "static conditions per end-point" as
you note, though we of course would want to include the possibility of
dynamic changes.

Regards, Frank

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Tuesday, October 21, 2008 8:15 PM
> Cc: Hannes Tschofenig; [email-masked]
> I would want to understand the difference between this and 
> the Gq' application that now exists. Just from your words: is 
> it that you are talking about imposing static conditions per 
> end point rather than per-session control?
> 
> >> * The term CGN refers to the ongoing IPv4/IPv6 transition work, 
> >> right? If so, I was not aware that they wanted to use an 
> protocol to 
> >> request mappings to be created. Instead, the NAT bindings 
> are created 
> >> based on the flow of data traffic.
> >> Am I wrong? 
> > 
> re-use their 
> >> work to avoid duplicate coding efforts. The entire idea of using 
> >> Diameter in that space essentially comes from the MIDCOM days, see 
> >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't 
> >> really a AAA application as such (since the AAA server is not 
> >> involved there).
> > 
> >> allocating NAT bindings or also QoS parameters and firewalling 
> >> functionality?
> > 
> >> planning to deploy a CGN in the next year.  I have been 
> developing a 
> >> set of AAA requirements to support such deployements over the past 
> >> month.
> >> 	 
> >> 			full draft, but wanted to get the 
> abstract out asap so that the 
> >> work can
> >> 			  CGNC application allows gateways 
> (e.g. Network Access Server 
> >> (NAS))
> >> 			to
> >> 			  interact with Carrier-Grade NAT (CGN) 
> devices. The interaction 
> >> is to
> >> 			  gateway and CGN. It is to allow the 
> gateway to control and 
> >> manage the
> >> 			
> >> 			  to provide information relevant to 
> accounting purposes to the 
> >> gateway
> >>

---

From: "David Frascone" <[email-masked]>
Date: Wed, 22 Oct 2008 13:16:53 -0400

It is sounding like this may be somewhere we would want to focus some
attention as a WG, no?

-Dave

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 19:23:47 +0200

Tom, Frank,

Since were are talking about a control interface sitting just above the NAT device I would compare it to ITU-T Rw (Recommendation Q.3303.3)rather than ETSI Gq'. Having said that, I'm still not sure to understand the differences between this GCN control application and existing applications such as Gq' and Q.3303.3 (16777256). Both Gq' and Rw enable controlling more things than just NAT bindings. Is it a correct understanding that the Diameter application defined in Q.3303.3 is roughly equivalent to the GCN Control Application combined with the Diameter QoS Application but does not currently cover the first two items identified in Frank's message (i.e specify the maximum number of bindings per end-point & provide resports/stats)? Or is there another fundamental difference that I overlooked?

Best Regards
Bruno

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Frank Brockners (fbrockne)
Envoyé : mercredi 22 octobre 2008 18:25
À : Tom Taylor
Cc : [email-masked]
Objet : Re: [Dime] Dime rechartering: Include Carrier-Grade NATControlApplication?

Tom,

TISPAN Gq' includes NAT-binding control capabilities for sessions at the service-layer (e.g. SIP sessions) - representing services provided by the SP: Among other things, Gq' allows P-CSCF to request allocation and/or modification of a binding in BGF for a specific media flow. This makes BGF an anchor point and natural NAT gateway for service-layer controlled traffic. Hence, Gq' is focused on controlling individual bindings for service-level traffic flows.

Different from that, the CGN Control application is intended as a control interface to the CGN, i.e. a NAT device placed between subscriber-CPE and the public Internet by a carrier - typically traversed by all the traffic (deployment dependent minus the traffic handled by BGFs). As noted earlier, bindings within the CGN would typically not be created through an external interface (with per-binding signaling procedures) but be created on the fly within the CGN. A CGN and a BGF would typically operate in parallel - where CGN would provide NAT-services for all of the traffic that is not "steered" towards a BGF by a P-CSCF (or similar). Still, it is desirable to control and monitor some of the behavior of the CGN on a per end-point (or subscriber) basis, i.e. restrict the number of bindings per subscriber, pre-set certain ip-address/port-ranges, report allocated bindings etc. Given that those rules are typically per subscriber (and won't change frequently), one could call this "static conditions per end-point" as you note, though we of course would want to include the possibility of dynamic changes.

Regards, Frank

> I would want to understand the difference between this and the Gq' 
> application that now exists. Just from your words: is it that you are 
> talking about imposing static conditions per end point rather than 
> per-session control?
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:06:12 +0200

Bruno,

hmm - I agree that Rw/Q.3303.3 has some NAT and QoS control capabilities, though wrt/ NAT, Rw also largely follows the assumption of an external entity (i.e. a P-CSCF) which controls the allocation of bindings within the gateways (i.e. request creation/modification/removal of bindings)- which is fundamentally different from a typical environment where a CGN would get deployed. For CGN one would typically not have an external controller request allocation of specific bindings - but create bindings from pre-defined pools "on the fly". All a CGN-Control app would do is control the basic behavior of the CGN for all/most of the binding per subscriber/end-point (and the allocation of a specific binding on a per request basis is really a corner case, which would be the exception rather than the rule). As noted earlier - I'm working on a full draft - which should provide more background and also be a solid base for discussions (unfortunately it does not evolve as quickly as I'd wish because of ongoing internal & external discussions with interested parties).

Regards, Frank

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 7:24 PM
> To: Frank Brockners (fbrockne); [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Dime rechartering: Include Carrier-Grade 
> NATControlApplication?
> 
> Tom, Frank,
> 
> Since were are talking about a control interface sitting just 
> above the NAT device I would compare it to ITU-T Rw 
> (Recommendation Q.3303.3)rather than ETSI Gq'. Having said 
> that, I'm still not sure to understand the differences 
> between this GCN control application and existing 
> applications such as Gq' and Q.3303.3 (16777256). Both Gq' 
> and Rw enable controlling more things than just NAT bindings. 
> Is it a correct understanding that the Diameter application 
> defined in Q.3303.3 is roughly equivalent to the GCN Control 
> Application combined with the Diameter QoS Application but 
> does not currently cover the first two items identified in 
> Frank's message (i.e specify the maximum number of bindings 
> per end-point & provide resports/stats)? Or is there another 
> fundamental difference that I overlooked?
> 
> Best Regards
> Bruno
> 
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Frank Brockners (fbrockne) Envoyé : mercredi 22 
> octobre 2008 18:25 À : Tom Taylor Cc : [email-masked] Objet : 
> Re: [Dime] Dime rechartering: Include Carrier-Grade 
> NATControlApplication?
> 
> Tom,
> 
> TISPAN Gq' includes NAT-binding control capabilities for 
> sessions at the service-layer (e.g. SIP sessions) - 
> representing services provided by the SP: Among other things, 
> Gq' allows P-CSCF to request allocation and/or modification 
> of a binding in BGF for a specific media flow. This makes BGF 
> an anchor point and natural NAT gateway for service-layer 
> controlled traffic. Hence, Gq' is focused on controlling 
> individual bindings for service-level traffic flows.
> 
> Different from that, the CGN Control application is intended 
> as a control interface to the CGN, i.e. a NAT device placed 
> between subscriber-CPE and the public Internet by a carrier - 
> typically traversed by all the traffic (deployment dependent 
> minus the traffic handled by BGFs). As noted earlier, 
> bindings within the CGN would typically not be created 
> through an external interface (with per-binding signaling 
> procedures) but be created on the fly within the CGN. A CGN 
> and a BGF would typically operate in parallel - where CGN 
> would provide NAT-services for all of the traffic that is not 
> "steered" towards a BGF by a P-CSCF (or similar). Still, it 
> is desirable to control and monitor some of the behavior of 
> the CGN on a per end-point (or subscriber) basis, i.e. 
> restrict the number of bindings per subscriber, pre-set 
> certain ip-address/port-ranges, report allocated bindings 
> etc. Given that those rules are typically per subscriber (and 
> won't change frequently), one could call this "static 
> conditions per end-point" as you note, though we of course 
> would want to include the possibility of dynamic changes.
> 
> Regards, Frank
> 
> > >> 			  the Diameter Carrier-Grade NAT 
> Control (CGNC) application.  
> > >> The
> > >> 			Diameter

---

From: Tina TSOU <[email-masked]>
Date: Thu, 23 Oct 2008 15:08:10 +0800

Hi all,
Here is Diameter Routing Problem Statement draft for your comments.

Filename:    draft-ietf-dime-routing-problem-statement
Version:    00
Staging URL:    http://www3.ietf.org/proceedings/staging/draft-ietf-dime-routing-problem-statement-00.txt
Title:    Diameter Routing Problem Statement
Creation_date:    2008-10-19
WG ID:    dime
Number_of_pages: 8
Abstract:
This document describes use cases that suggest requirements to be
able to add constraints to the existing Diameter routing mechanisms.

B. R.
Tina