Subject: [PCN] PCN architecture, new addressing sub-section

From: <[email-masked]>
Date: Wed, 8 Aug 2007 23:14:51 +0100

This is to flag up that I wrote a new sub-section (in Section 5,
Detailed functional architecture) about addressing:

5.7.  Addressing

   PCN-nodes may need to know the address of other PCN-nodes:

   o  in all cases PCN-interior-nodes don't need to know the address of

      any other PCN-nodes, except their next hop neighbours

   o  in the cases of admission or termination decision by a PCN-

      boundary-node, the PCN-egress-node needs to know the address of

      the PCN-ingress-node associated with a flow, at a minimum so that

      the PCN-ingress-node can be informed to enforce the admission

      decision through policing.  The addressing information can be

      gathered from signalling, for example as described for RSVP in

      [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic is

      always tunnelled across the PCN-domain, then the PCN-ingress-

      node's address is simply the source address of the outer packet

      header.

   o  in the cases of admission or termination decision by a central

      control node, the PCN-egress-node needs to be configured with the

      address of the centralised node.  In addition, depending on the

      exact deployment scenario and its signalling, the centralised node

      may need to know the addresses of the PCN-ingress-node and PCN-

      egress-node, and the PCN-egress-node know the address of the PCN-

      ingress-node.  NOTE: Consideration of the centralised case is out

      of scope of the initial PCN WG Charter.

(I'm not completely happy with it. I'm not sure it captures sufficiently
the discussion there was a month or two back about different ways the
egress could know the ingress address. Also, I wonder if the description
of the centralised node case is too long, as the case is strictly out of
scope.)

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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 10 Aug 2007 16:52:04 -0400

See my comments below demarked with [Joe].

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: August 8, 2007 6:15 PM
To: [email-masked]
Subject: [PCN] PCN architecture, new addressing sub-section

5.7.  Addressing

      header.

[Joe] I believe that the PCN-ingress-node should enforce both the
admission and flow termination decisions. So would suggest that the
above text be modified "... enforce the admission and flow termination
decision through policing." [end]

[Joe] Would also like to add that probing can be used to discover and
exchange address information of PCN-boundary-nodes. "Another method that
may be used to discover and exchange address information between
PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP
header information of the flow to be admitted generates and sends probe
packets that can easily be detected by the PCN-egress-node. The sent
probe packets contain as payload the address of the PCN-ingress-node so
that the PCN-egress-node knows where to send the pre-congestion
information for that flow." [end]

[Joe] I think we need a bit more discussion about the central control
node. I'm thinking of something like a PDP where pre-congestion
information is sent to and after verifying the policy the result is sent
to PCN-ingress-node to care out the action. For this scenario, the
PCN-boundary-nodes need to be provisioned with the address of the
central policy control node. [end]

[Joe] Can the proponents of the central control node expand a bit more
on how this will work? [end]

---

From: Tina TSOU <[email-masked]>
Date: Mon, 13 Aug 2007 14:32:19 +0800

----- Original Message ----- 
  From: Jozef Babiarz 
  To: [email-masked] ; [email-masked] 
  Sent: Saturday, August 11, 2007 4:52 AM
  Subject: RE: [PCN] PCN architecture, new addressing sub-section

  Regards, Joe 
  email:[email-masked] 
  Telephone:613-763-6098 

------------------------------------------------------------------------------

  This is to flag up that I wrote a new sub-section (in Section 5, Detailed functional architecture) about addressing:

  5.7.  Addressing

        header.

  [Joe] I believe that the PCN-ingress-node should enforce both the admission and flow termination decisions. So would suggest that the above text be modified "... enforce the admission and flow termination decision through policing." [end]

  [Tina: sounds excellent.] 

  [Joe] Would also like to add that probing can be used to discover and exchange address information of PCN-boundary-nodes. "Another method that may be used to discover and exchange address information between PCN-boundary-nodes is through probing. The PCN-ingerss-node using the IP header information of the flow to be admitted generates and sends probe packets that can easily be detected by the PCN-egress-node. The sent probe packets contain as payload the address of the PCN-ingress-node so that the PCN-egress-node knows where to send the pre-congestion information for that flow." [end]

  [Tina: I found there is similarity between this probe method and RSVP method. The PCN ingress node places its address in the probe packet or RSVP PATH message, the interior nodes doesn't care about these packets, the PCN egress node could associate the flow with the correct PCN ingress node after extracting the address of the PCN ingress node embedded in the probe packet or RSVP PATH message.
  These kinds of methods have a disadvantage: it's hard for the egress node to merge the flows. A PCN egress node may create a mapping table like follows:
  FLOW    FLOW's Ingress node
  flow1    Ingress A
  flow2    Ingress A
  flow3    Ingress B
  flow4    Ingress B
  If there are too many flows, the table may be very large.
  One option to solve addressing of PCN-boundary node may be to use symmetric route. For example, supposing IBGP is running on the PCN-boundary node:
  1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress B----2.2.2.0/24
  IBGP could tell the egress node B that it has to go through PCN ingress A to reach 1.1.1.0/24, the egress node B could then regard a packet from 1.1.1.0/24 will come through ingress A, given a symmetric route scenario.
  The disadvantage of this option may be the requirement of symmetric route. The advantage of this option is that merged table item may be supported.
  Network   Network's Ingress node
  1.1.1.0/24   Ingress A] 

  [Joe] I think we need a bit more discussion about the central control node. I'm thinking of something like a PDP where pre-congestion information is sent to and after verifying the policy the result is sent to PCN-ingress-node to care out the action. For this scenario, the PCN-boundary-nodes need to be provisioned with the address of the central policy control node. [end]

  [Joe] Can the proponents of the central control node expand a bit more on how this will work? [end]

  [Tina: A centralized node will not burden the addressing of PCN-boundary nodes. To make metering, the egress node always has to know the ingress node address a flow associated. A centralized node makes the egress node doesn't need to notify the pre-congestion information (CLE) to the ingress node, instead, the egress node will send it to the centralized node. So the address of the centralized node has to be provisioned on the egress node. When the egress node notifies the CLE to the centralized node, it has to send the ingress node address associated the CLE. So the centralized would know the address of every PCN boundary node.]

  (I'm not completely happy with it. I'm not sure it captures sufficiently the discussion there was a month or two back about different ways the egress could know the ingress address. Also, I wonder if the description of the centralised node case is too long, as the case is strictly out of scope.)

------------------------------------------------------------------------------

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 15 Aug 2007 14:26:16 -0400

See additional comments demarked with [Joe1] below.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: Tina TSOU [mailto:[email-masked]] 
Sent: August 13, 2007 2:32 AM
To: [email-masked]; [email-masked]; Babiarz, Jozef (CAR:0S03)
Subject: Re: [PCN] PCN architecture, new addressing sub-section

	----- Original Message ----- 

	From: Jozef Babiarz <mailto:[email-masked]>  

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	5.7.  Addressing

	   o  in all cases PCN-interior-nodes don't need to know the
address of

	   o  in the cases of admission or termination decision by a
PCN-

	      boundary-node, the PCN-egress-node needs to know the
address of

	      the PCN-ingress-node associated with a flow, at a minimum
so that

	      the PCN-ingress-node can be informed to enforce the
admission

	      decision through policing.  The addressing information can
be

	      gathered from signalling, for example as described for
RSVP in

	      [I-D.lefaucheur-rsvp-ecn].  Alternatively, if PCN-traffic
is

	      always tunnelled across the PCN-domain, then the
PCN-ingress-

	      node's address is simply the source address of the outer
packet

	      header.

	[Joe] I believe that the PCN-ingress-node should enforce both
the admission and flow termination decisions. So would suggest that the
above text be modified "... enforce the admission and flow termination
decision through policing." [end]

	[Joe] Would also like to add that probing can be used to
discover and exchange address information of PCN-boundary-nodes.
"Another method that may be used to discover and exchange address
information between PCN-boundary-nodes is through probing. The
PCN-ingerss-node using the IP header information of the flow to be
admitted generates and sends probe packets that can easily be detected
by the PCN-egress-node. The sent probe packets contain as payload the
address of the PCN-ingress-node so that the PCN-egress-node knows where
to send the pre-congestion information for that flow." [end]

	[Tina: I found there is similarity between this probe method and
RSVP method. The PCN ingress node places its address in the probe packet
or RSVP PATH message, the interior nodes doesn't care about these
packets, the PCN egress node could associate the flow with the correct
PCN ingress node after extracting the address of the PCN ingress node
embedded in the probe packet or RSVP PATH message.
	These kinds of methods have a disadvantage: it's hard for the
egress node to merge the flows. A PCN egress node may create a mapping
table like follows:

	[Joe1] I do not see a need to merge flows in egress node for
admission control if probing is used. Also, no need to build and
maintain ingress-egress flow aggregating tables or perform rate
measurements of marked or unmarked PCN traffic if the marking as in 3sm
draft is used. [end]

	FLOW    FLOW's Ingress node
	flow1    Ingress A
	flow2    Ingress A
	flow3    Ingress B
	flow4    Ingress B
	If there are too many flows, the table may be very large.
	One option to solve addressing of PCN-boundary node may be to
use symmetric route. For example, supposing IBGP is running on the
PCN-boundary node:
	1.1.1.0/24----PCN Ingress A---PCN interior node-----PCN Egress
B----2.2.2.0/24
	IBGP could tell the egress node B that it has to go through PCN
ingress A to reach 1.1.1.0/24, the egress node B could then regard a
packet from 1.1.1.0/24 will come through ingress A, given a symmetric
route scenario.
	The disadvantage of this option may be the requirement of
symmetric route. The advantage of this option is that merged table item
may be supported.
	Network   Network's Ingress node
	1.1.1.0/24   Ingress A] 

	   o  in the cases of admission or termination decision by a
central

	      control node, the PCN-egress-node needs to be configured
with the

	      address of the centralised node.  In addition, depending
on the

	      exact deployment scenario and its signalling, the
centralised node

	      may need to know the addresses of the PCN-ingress-node and
PCN-

	      egress-node, and the PCN-egress-node know the address of
the PCN-

	      ingress-node.  NOTE: Consideration of the centralised case
is out

	[Joe] I think we need a bit more discussion about the central
control node. I'm thinking of something like a PDP where pre-congestion
information is sent to and after verifying the policy the result is sent
to PCN-ingress-node to care out the action. For this scenario, the
PCN-boundary-nodes need to be provisioned with the address of the
central policy control node. [end]

	[Joe] Can the proponents of the central control node expand a
bit more on how this will work? [end]

	[Tina: A centralized node will not burden the addressing of
PCN-boundary nodes. To make metering, the egress node always has to know
the ingress node address a flow associated. A centralized node makes the
egress node doesn't need to notify the pre-congestion information (CLE)
to the ingress node, instead, the egress node will send it to the
centralized node. So the address of the centralized node has to be
provisioned on the egress node. When the egress node notifies the CLE to
the centralized node, it has to send the ingress node address associated
the CLE. So the centralized would know the address of every PCN boundary
node.]

	(I'm not completely happy with it. I'm not sure it captures
sufficiently the discussion there was a month or two back about
different ways the egress could know the ingress address. Also, I wonder
if the description of the centralised node case is too long, as the case
is strictly out of scope.)

---

From: <[email-masked]>
Date: Mon, 20 Aug 2007 08:37:30 +0100

Joe, 

Will add something about probing to the addressing section.

Tina, not entirely sure what you mean about merging. There is some text
near the start of section 4 that may be useful?

PCN-ingress-nodes are flow-aware (required for policing purposes).  In

      several deployment scenarios PCN-egress-nodes will also be flow

      aware.  (Normally this adds no complexity since a PCN-boundary-

      node acts as both a PCN-ingress-node and as a PCN-egress-node.)

phil

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: 15 August 2007 19:26
To: Tina TSOU; [email-masked]; Eardley,PL,Philip,CXR9 R
Subject: RE: [PCN] PCN architecture, new addressing sub-section

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

 

	----- Original Message ----- 

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	5.7.  Addressing

	      header.

	FLOW    FLOW's Ingress node
	flow1    Ingress A
	flow2    Ingress A
	flow3    Ingress B
	flow4    Ingress B

---

From: Tina TSOU <[email-masked]>
Date: Wed, 22 Aug 2007 16:17:09 +0800

Hi Phil,
You are also right.
Allowing Egress Node flow aware implies that allowing in Egress Node to establish such table as below.
FLOW    FLOW's Ingress node
flow1    Ingress A
flow2    Ingress A
flow3    Ingress B
flow4    Ingress B
It is considered that such table could be rather big.

Considering an Edge Node as both Ingress and Egress, It is a good idea to let both share the flow status. I support Phil. However, I feel that it makes sense only for the bi-directional symmetric flow, now, as a Edge node, the maintained flow status could be as below.
FLOW Peer Edge Policies
flow1 A  XX
flow2 A  XX
flow3 B  XX
flow4 B  XX
Each entry could be interpreted like that some flow passes me to a peer edge (Egress), or from peer edge (Ingress) reaches me. That's OK, as long as it is for bidirectional symmetric flow.   

If PCN-egress-node is not flow-aware, there is an optional method, i.e. form the symmetric cross-domain routing to derive flow and Ingress-Egress matching relationship.

B. R.
Tina
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Monday, August 20, 2007 3:37 PM
  Subject: RE: [PCN] PCN architecture, new addressing sub-section

  Joe, 

  Tina, not entirely sure what you mean about merging. There is some text near the start of section 4 that may be useful?

  phil

  -----Original Message-----
  From: Jozef Babiarz [mailto:[email-masked]] 
  Sent: 15 August 2007 19:26
  To: Tina TSOU; [email-masked]; Eardley,PL,Philip,CXR9 R
  Subject: RE: [PCN] PCN architecture, new addressing sub-section

  Regards, Joe 
  email:[email-masked] 
  Telephone:613-763-6098 

    ----- Original Message ----- 

    From: Jozef Babiarz 

    Regards, Joe 
    email:[email-masked] 
    Telephone:613-763-6098 

----------------------------------------------------------------------------

    5.7.  Addressing

          header.

    [Joe1] I do not see a need to merge flows in egress node for admission control if probing is used. Also, no need to build and maintain ingress-egress flow aggregating tables or perform rate measurements of marked or unmarked PCN traffic if the marking as in 3sm draft is used. [end]

    FLOW    FLOW's Ingress node
    flow1    Ingress A
    flow2    Ingress A
    flow3    Ingress B
    flow4    Ingress B

----------------------------------------------------------------------------