80 likes | 87 Views
PWE3 Architecture PWE3 IETF-56 16-21 March 2003. Stewart Bryant <stbryant@cisco.com>. 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
E N D
PWE3 ArchitecturePWE3 IETF-56 16-21 March 2003 Stewart Bryant <stbryant@cisco.com>
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.
Generic Control Word 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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
Why is PID mandatory – 1/2 • IP flow recognition within switch path is an important tool. • (counter n/w attack & n/w abuse, n/w planning, usage billing, • load balance) • 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. • Therefore an MPLS packet needs a IP protocol type indicator. • Hence • PID = 0 PWE3 • PID = 4 IPv4 • PID = 6 IPv6
Why is PID mandatory – 2/2 • 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. • PWE3 should therefore reject any CW design that destroys the ability to identify IP packet types. • The IETF should deprecate the deployment of existing protocols that fail to meet the IP packet identification requirement.
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.
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.
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?