[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
PWE3                                                          Y(J) Stein
Internet-Draft                                   RAD Data Communications
Expires: January 9, 2005                                   July 11, 2004


                             UDP based PWs
                      draft-stein-pwe3-udp-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   The PWE3 charter permits three PSN types, namely "IP (both versions),
   L2TP, or MPLS".  The majority of drafts submitted to the working
   group have focused on MPLS PSNs, and lesser attention has been given
   to L2TPv3.  Only the TDMoIP drafts have explicitly specified UDP/IP
   as PSN, and only they stipulate the use of UDP port numbers as PW
   labels.  This draft discusses PWs based on UDP/IP, concentrating on
   three issues, namely 1) the advisability of using UDP port numbers as
   PW labels, 2) which UDP port number to use, and 3) what label
   distribution protocol should be employed.






Stein                    Expires January 9, 2005                [Page 1]


Internet-Draft                   UDP-PWs                       July 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Using UDP Port Numbers . . . . . . . . . . . . . . . . . . . .  4
   3.  Source or Destination Port . . . . . . . . . . . . . . . . . .  4
   4.  Port Number Distribution Protocol  . . . . . . . . . . . . . .  6
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   8.  IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . .  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  9





































Stein                    Expires January 9, 2005                [Page 2]


Internet-Draft                   UDP-PWs                       July 2004


1. Introduction

   Although sanctioned as a valid PSN by the PWE3 charter, little work
   has been carried out concerning PWs over UDP/IP.  In fact, use of
   UDP/IP seems to be mentioned only in two WG drafts.

   The PWE3 architecture draft [PWE3-ARCH] mentions the use of UDP, and
   states:

      PW Demultiplexing is provided by the PW label, which may take the
      form specified in a number of IETF protocols,  e.g. an MPLS label,
      an L2TP session ID, or a UDP port number.

   Of the service-specific drafts, only the TDMoIP drafts have
   explicitly specified UDP/IP as PSN, and although these drafts have
   stimulated much comment, their non-standard use of UDP ports has not
   provoked discussion.

   Unlike MPLS and L2TP, UDP/IP does not provide a transport tunneling
   mechanism within which PWs are placed.  However, UDP ports can
   provide addressing functionality for the PWs themselves, by
   populating a port field with the PW label.

   The use of UDP ports as PW labels has been implemented by several
   vendors, and is widely deployed for TDM PWs.  The use of UDP/IP as
   the PSN is particularly appropriate for CE to CE PWs [CE2E], since
   the MPLS network is presently confined to the PEs.

   This draft discusses PWs based on UDP/IP, concentrating on three
   issues, namely

   1) the fundamental advisability of using UDP port numbers as PW
      labels, (see Section 2)

   2) whether to place the PW label in source or destination port (see
      Section 3), and

   3) the label distribution protocol that should be employed (see
      Section 4).












Stein                    Expires January 9, 2005                [Page 3]


Internet-Draft                   UDP-PWs                       July 2004


2. Using UDP Port Numbers

   The majority of PWE drafts assume an MPLS (inner) label as PW label.
   This is because most PWE work have focused on MPLS PSNs, as the basic
   PWE architecture has been designed for service-provider scenarios.
   MPLS is not presently available at end-user sites, and so MPLS-based
   PWs are not directly applicable to CE-CE scenarios (but see [CE2E]).
   In particular, enterprise applications where native services are
   converted to IP at the customer premises, require PWs based on pure
   IP, specifically UDP/IP.

   The raison d'etre of the PW demultiplexer label is to allow multiple
   PWs to be carried in a single tunnel, or for the UDP/IP case, between
   two end systems.  The PW label is situated in the packet overhead,
   somewhere before the PWE3 Encapsulation Layer, and employs mechanisms
   pre-existing in the PSN headers.

   In addition to IP addresses, UDP/IP and TCP/IP employ 16-bit port
   numbers.  The allocation of port numbers is performed by IANA, with
   ôwell known port numbersö in the range from 0 through 1023,
   ôregistered port numbersö from 1024 through 49151, and ôdynamic or
   private port numbersö from 49152 through 65535.

   As aforementioned, the architecture draft specifically allows the use
   of UDP port numbers as PW labels.  Since UDP always reserves space
   for source and destination UDP port numbers, exploiting these fields
   saves inserting additional overhead to the PW packet (as would be
   required were L2TPv3 to be used).





3. Source or Destination Port

   Unfortunately, the TCP and UDP standards themselves (RFCs 793 and
   768, respectively) do not mandate methods for port number use.  In
   particular RFC 768 merely states:

      Source Port is an optional field, when meaningful,
      it indicates the port of the sending process,
      and may be assumed to be the port to which a
      reply should be addressed in the absence of any other information.
      If not used, a value of zero is inserted.

      Destination Port has a meaning within the context of a
      particular Internet destination address.




Stein                    Expires January 9, 2005                [Page 4]


Internet-Draft                   UDP-PWs                       July 2004


   While the TCP text is more descriptive, it is equally noncommittal:

      To allow for many processes within a single Host to use TCP communication
      facilities simultaneously, the TCP provides a set of addresses or ports
      within each host. à
      The binding of ports to processes is handled independently by each host.
      However, it proves useful to attach frequently used processes à
      to fixed sockets which are made known to the public.
      These services can then be accessed through the known addresses.
      Establishing and learning the port addresses of other processes
      may involve more dynamic mechanisms.

   The primary use of TCP and UDP port numbers is application
   demultiplexing, with requests to an IP server being forwarded to the
   appropriate application based on the well known or registered
   destination port number.

   VoIP and other RTP-based protocols [RTP] use the destination port for
   connection demultiplexing, whereby multiple connections carrying data
   destined for the same application are distinguished based on their
   dynamic port numbers.  Adopting this strategy would lead us to place
   the PW label in the destination port.  Such use excludes the capacity
   to demultiplex applications based on the content of this port.  While
   this loss is not overly problematic, as sessions are setup in an
   orderly way and packets do not arrive unexpected, this use
   constitutes a break with tradition.

   Using a port number field is superior to adding a non-standard field,
   since available hardware components can switch based on these fields
   in the IP header.  Were we to desire maintaining the traditional use
   of destination port as application demultiplexer, we could place the
   PW label in the source port field.  This is equally untraditional,
   but exploits a 16-bit field that would otherwise be unused.  It has
   the additional advantage of begin compatible with enterprise
   scenarios where NATs and firewalls are employed.

   NAPT devices [RFC 2391] classify incoming packets based on
   destination IP address and port number.  Firewalls [RFC 2979] may use
   source IP address as well.  A server sitting behind a NAPT or
   firewall may be accessed based on a known destination port number
   resulting in packets being correctly routed.  NAPT and firewalls that
   adaptively learn mappings can function properly with dynamically
   allocated destination port numbers, only when the connection
   originator sits on their local side.







Stein                    Expires January 9, 2005                [Page 5]


Internet-Draft                   UDP-PWs                       July 2004


4. Port Number Distribution Protocol

   A typical client-server protocol, such as telnet [TELNET], has the
   server wait for an incoming connection by monitoring a well-known
   port W.  The client process, before initiating a connection, selects
   an unused port number P.  It then sends a packet to the server with
   destination port W and source port P.  The serverÆs responses are
   sent using destination port P and source port W.  Thus, a
   bidirectional but asymmetric connections are established without any
   explicit setup protocol.

   This idea can be extended to the more symmetric case.  For example,
   in tftp [TFTP] both sides select identifiers, say P and Q.  The
   initiator sends a packet with destination port set to well-known port
   W and source set to P.  The response has destination P and source Q,
   and only P and Q are used for the duration of the session.

   In both of the above cases the port numbers were chosen by their
   source (upstream allocation).  Downstream allocation is also used,
   for example by passive mode ftp [FTP].  Here the client issues a
   command to a well-known port and the server responds with a message
   containing the port number P to be used.

   As an alternative to such implicit port number allocations, UDP/IP
   PWs may be set up using an explicit control protocol.  An obvious
   possibility is the standard PWE control protocol based on targeted
   LDP.  This has the advantage of settling on a single control protocol
   for all PW types except L2TPv3, and could be extended to additional
   cases (e.g.  allocation of VLAN tags [VLAN]).  It has the shortcoming
   of using LDP in a non-MPLS environment.  Only minor changes would be
   required to the LDP protocol for this use, mainly related to the
   different label ranges (UDP port numbers are only 16 bits in length,
   VLAN tags are 12 bits.)

5. Summary

   The main questions raised in this draft are herein summarized.

   Should UDP/IP PSNs, specified in the PWE charter and the architecture
   draft, continue to be supported?

   Should the PW label be placed in the source or destination UDP port?
   Do we need registered port numbers for PWs?

   What method should be used for label selection and distribution?
   Should the label selection by upstream or downstream? Should an
   implicit or explicit distribution protocol be used? Do we want to
   standardize a single PWE control protocol?



Stein                    Expires January 9, 2005                [Page 6]


Internet-Draft                   UDP-PWs                       July 2004


6. Security Considerations

   PWs do not enhance or detract from the security performance of the
   underlying PSN, and PWs running over UDP/IP will suffer from the same
   weaknesses as any other traffic on the same network.

   PW labels used as UDP port numbers that are known or can be readily
   surmised may pose security threats.

7. IANA Considerations

   Depending on the label distribution protocol, use of UDP ports Will
   require allocation of registered port numbers for the various PW
   types.  0x085E (2142) has already been assigned by IANA to TDMoIP
   PWs.

8. IPR Disclosure Acknowledgement

   By submitting this Internet-Draft, we certify that any applicable
   patent or other IPR claims of which we are aware have been disclosed,
   and any of which we become aware will be disclosed, in accordance
   with RFC 3668.





























Stein                    Expires January 9, 2005                [Page 7]


Internet-Draft                   UDP-PWs                       July 2004


9. References

   [L2TPv3] draft-ietf-l2tpext-l2tp-base-10.txt (08/03) Layer Two
      Tunneling Protocol (L2TPv3), J.  Lau et al., work in progress

   [MPLS] RFC 3032 MPLS Label Stack encoding

   [PWE3-ARCH] draft-ietf-pwe3-arch-07.txt (3/04), PWE3 Architecture,
      Stewart Bryant et al, work in progress

   [PWCE2E] draft-stein-pwe3-pwce2e-00.txt (3/04), Pseudowire Customer
      Edge to Customer Edge Emulation, Y(J) Stein, work in progress

   [RTP] RFC 3550 RTP: Transport Protocol for Real-Time Applications

   [TCP] RFC 793 Transmission Control Protocol (TCP)

   [TELNET] RFC 854 Telnet Protocol Specification

   [TFTP] RFC 1350 The TFTP Protocol (Revision 2)

   [UDP] RFC 768 User Datagram Protocol (UDP)

   [VLAN] IEEE 802.1Q, IEEE Standards for Local and Metropolitan Area
      Networks ù Virtual Bridged Local Area Networks (2003)


10. Acknowledgments

   The author would like to thank Sasha Vainshtein and Stewart Bryant
   for interesting discussion and valuable contributions to the options
   herein presented.


Author's Address

   Yaakov (Jonathan) Stein
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg C
   Tel Aviv  69719
   ISRAEL

   Phone: +972 3 645-5389
   EMail: yaakov_s@rad.com







Stein                    Expires January 9, 2005                [Page 8]


Internet-Draft                   UDP-PWs                       July 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

































Stein                    Expires January 9, 2005                [Page 9]