Subject: [PCN] Handling of ECN and intra-PCN-domain tunnels in 3-in-1-encoding

From: Michael Menth <[email-masked]>
Date: Mon, 14 Mar 2011 14:59:40 +0100

Hi all,

Section 3.2 of 3-in-1-encoding
http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-04#section-3.2
explains why 3-in-1-encoding looks as it does and Section 3.3 makes 
clear that it reqires RFC6040.
Section 6 of 3-in-1-encoding
http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-04#section-6
explains only how compatibility with baseline encoding is achieved.

However, we did not explicitly say:
1) How ECN traffic should be handled across PCN domains
2) How tunnels are set up within PCN domains (only shortly mentioned in 
the conclusion)

I think that an addition along the following lines makes this clearer 
and reflects the email thread we just had, at least I hope so.

1) Handling of ECN traffic across PCN domains

There are currently two options for handling ECN traffic across PCN domains.
a) The PCN ingress node resets the ECN field to NM.
    The PCN egress node resets the ECN field to not-ECT.
    Thereby, ECN functionality is disabled.
b) A tunnel is set up across the PCN domain from the PCN ingress node 
towards the PCN egress node according to RFC6040.
    That means, the PCN ingress node encapsulates packets towards the 
PCN egress node.
    Then, PCN ingress and egress node perform the operations listed at a)
    Then, the PCN egress node decapsulates packets according to RFC6040.
    Thereby, the original ECN codepoints are restored in the packet headers.

2) Setting up Tunnels within PCN domains

    A tunnel may be set up from node A to node B within a PCN domain 
according to the normal mode of RFC6040.
    That means, node A encapsulates a packet and copies the ECN field of 
the inner header to the outer header.
    Then, node B decapsulates the packet according to the rules in RFC6040.

Best wishes,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 14 Mar 2011 15:14:23 +0100

Hi Michael

Your proposal is fine for me!

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Menth
> Sent: maandag 14 maart 2011 15:00
> To: [email-masked]
> Subject: [PCN] Handling of ECN and intra-PCN-domain tunnels 
> in3-in-1-encoding
> 
> Hi all,
> 
> explains why 3-in-1-encoding looks as it does and Section 3.3 
> makes clear that it reqires RFC6040.
> 2) How tunnels are set up within PCN domains (only shortly 
> mentioned in the conclusion)
> 
> I think that an addition along the following lines makes this 
> clearer and reflects the email thread we just had, at least I hope so.
> 
> b) A tunnel is set up across the PCN domain from the PCN 
> ingress node towards the PCN egress node according to RFC6040.
>     That means, the PCN ingress node encapsulates packets 
> towards the PCN egress node.
>     A tunnel may be set up from node A to node B within a PCN 
> domain according to the normal mode of RFC6040.
>     That means, node A encapsulates a packet and copies the 
> ECN field of the inner header to the outer header.
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>