[PCN] new text about Tunnelling for architecture draft

Have tried to re-write the tunnelling section in the architecture draft
to reflect the recent emails:

Tunnelling (modified text for S5.8)

Tunnels may originate and/or terminate within a PCN-domain. It is
important that the PCN-marking of any packet can potentially influence
PCN's flow admission control and termination - it shouldn't matter
whether the packet happens to be tunnelled at the PCN-node that
PCN-marks the packet, or indeed whether it's decapsulated or
encapsulated by a subsequent PCN-node. 

This suggests that the "uniform conceptual model" described in [2983]
should be re-applied in the PCN context. In line with this and the
approach of [4303] and [draft-briscoe-tsvwg-ecn-tunnel], the following
rule is applied if encapsulation is done within the PCN-domain:

*        any PCN-marking is copied into the outer header    

Similarly, in line with the "uniform conceptual model" of [2983] and the
"full-functionality option" of [3168], the following rules are applied
if decapsulation is done within the PCN-domain:

*        if the outer header's marking state is more severe then it is
copied onto the inner header

*        NB the order of increasing severity is: unmarked; PCN-marking
with first encoding (ie associated with the PCN-lower-rate); PCN-marking
with second encoding (ie associated with the PCN-upper-rate)

The essential reason for the copying operations described above is to
simplify dealing with the various headers: PCN-marking is then
orthogonal to tunnel encapsulation /decapsulation. 

An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to
PCN-egress-nodes. The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved by PCN-colouring (Section 5.3) after
all the other functions. The potential reasons for doing such tunnelling
are: the PCN-egress-node then automatically knows the address of the
relevant PCN-ingress-node for a flow; even if ECMP is running, all
PCN-packets on a particular ingress-egress-aggregate follow the same
path. But it also has drawbacks, for example the additional overhead in
terms of bandwidth and processing. 

Open issues: (text for S6, second para is new)

Tunnelling: There are scenarios where tunnelling makes it hard to
determine the path in the PCN-domain. The problem, its impact and the
potential solutions are similar to those for ECMP. 

Partially PCN-capable tunnels: (1) The tunnel starts outside a
PCN-domain and finishes inside it. If the packet arrives at the tunnel
ingress with the same encoding as used within the PCN-domain to indicate
PCN-marking, then this could lead the PCN-egress-node to falsely measure
pre-congestion.  (2) The tunnel starts inside a PCN-domain and finishes
outside it. If the packet arrives at the tunnel ingress already
PCN-marked, then it will still have the same encoding when it's
decapsulated which could potentially confuse nodes beyond the tunnel
egress.  (3) Scenarios with partially PCN-capable tunnels may also make
it harder for the PCN-egress-node to gather from the signalling messages
(eg RSVP, NSIS) the identity of the PCN-ingress-node. 

Potential solutions: (out of scope of architecture draft, but I'll add a
ref to this email thread)

*        tunnel starts outside a PCN-domain and finishes inside it:
could require tunnel egress to drop such a packet. This is same approach
as in S3.5, where PCN-ingress-node drops packet.

*        tunnel starts inside a PCN-domain and finishes outside it:
could require the tunnel ingress to check (somehow) whether the tunnel
egress is outside the PCN-domain, and if it is then clear any
PCN-marking on the inner header.

*        Signalling and partially-capable PCN-tunnels: don't know, could
try something similar to nsis [rfc4080 S5.4]: < To signal for the
packets carrying the tunneled data, the tunnel is considered a new data
flow in its own right, and NSIS signaling is applied to it recursively.
This requires signaling support in at least one tunnel endpoint.> This
problem should be considered in the milestone doc about reqts for pcn
signalling. 