1 PWE3 Architecture PWE3 IETF March 2003 Stewart Bryant

222 PWE3 Architecture IETF-55 The Architecture Draft draft-ietf-pwe3-arch-02.txt Incorporates all the feedback received from the list, except that it: 1) Retains IETF terminology, and 2) Continues to use the reference models derived from the requirements draft. Subject to the following discussion points, we would like to take this draft to last call.

333 PWE3 Architecture IETF-55 Generic Control Word | PID | Flags |FRG| Length | Sequence Number | Need to add text saying optional may be used for other purposes For PW, PID = 0. Non-conformance by some drafts is a serious problem – see next slide

444 PWE3 Architecture IETF-55 Why is PID mandatory – 1/2 1)IP flow recognition within switch path is an important tool. (counter n/w attack & n/w abuse, n/w planning, usage billing, load balance) 2)In MPLS n/w, label aggregation means that we can infer no information WRT the packet content either by direct inspection of the outer label or by reference to stored label state. 3) Therefore to identify an IP flow we need to inspect the IP packet itself. This means that need to be able to determine that packet type is IP. 4)Therefore an MPLS packet needs a IP protocol type indicator. 5)Hence PID = 0  PWE3 PID = 4  IPv4 PID = 6  IPv6

555 PWE3 Architecture IETF-55 Why is PID mandatory – 2/2 5)Loss of the ability to distinguish between IP packet types and non-IP packet types would be a fundamental reduction in the functionality of the Internet Architecture. Such a change to the Internet Architecture is not within the grant of PWE3. 7)PWE3 should therefore reject any CW design that destroys the ability to identify IP packet types. 8)The IETF should deprecate the deployment of existing protocols that fail to meet the IP packet identification requirement.

666 PWE3 Architecture IETF-55 Congestion - Background Congestion aware transport is the safety valve of the Internet. PWE3 is in the Transport Area because the transport area understands congestion management. Although PWE3 will often be constrained to a single SP, the technology can and will be deployed across the Internet.

777 PWE3 Architecture IETF-55 Congestion – Summary of draft Derived from text supplied by RTP WG Where the payload is KNOWN to be TCP friendly, and backs off the offered load under loss: no further mechanism is REQUIRED. If an enhanced PSN is being used the PW SHOULD verify this, and assume the worst In all other cases the PW must provide a loss sensitive back-off mechanism by for example: Shutting down one or more PWs Applying some native mechanism in the NSP The criteria is that the PW thoughput is less than or equal to the LONG term average TCP throughput operating under similar congestion conditions.

888 PWE3 Architecture IETF-55 Issues Do we need the safety valve – can we get away with TE and input policing? Does the requirement for perfect emulation (& SP SLA cost) exceed the requirement for congestion management ? So we detect congestion, then what do we do? Can we trust some traffic classes? Can we use control plane congestion as a proxy? Finally – is the text in the arch draft the “necessary and sufficient” description of the PWE3 approach to congestion?