[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-wijnands-pim-proxy) 00

PIM WG                                                          A. Boers
Internet-Draft                                              IJ. Wijnands
Expires: August 5, 2005                                         E. Rosen
                                                     Cisco Systems, Inc.
                                                           february 2005


                      Format for using PIM proxies
                        draft-ietf-pim-proxy-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 5, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a generic TLV encoding format to be added to
   PIM.






Boers, et al.            Expires August 5, 2005                 [Page 1]


Internet-Draft            The PIM Proxy format             february 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Use of the Proxy Field in Join Messages  . . . . . . . . . . .  3
     2.1   Proxy join . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2   Transitive proxies . . . . . . . . . . . . . . . . . . . .  3
     2.3   Proxy Hello Option . . . . . . . . . . . . . . . . . . . .  3
     2.4   Conflicting Proxies  . . . . . . . . . . . . . . . . . . .  3
     2.5   Proxy Convergence  . . . . . . . . . . . . . . . . . . . .  4
     2.6   Multiple Proxies . . . . . . . . . . . . . . . . . . . . .  4
   3.  PIM Proxy packet format  . . . . . . . . . . . . . . . . . . .  5
     3.1   PIM Join packet format . . . . . . . . . . . . . . . . . .  5
     3.2   PIM Proxy Hello option . . . . . . . . . . . . . . . . . .  5
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1   Normative References . . . . . . . . . . . . . . . . . . .  6
     5.2   Informative References . . . . . . . . . . . . . . . . . .  6
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  6
       Intellectual Property and Copyright Statements . . . . . . . .  7
































Boers, et al.            Expires August 5, 2005                 [Page 2]


Internet-Draft            The PIM Proxy format             february 2005


1.  Introduction

   It is sometimes convenient to add additional information to PIM join
   messages.  The generic PIM encoding format is not allways optimal
   todo this.  This document defines a new field in the PIM Join
   message, called the "Proxy" field.  The contents and purpose of this
   proxy field is not outside the scope of this document, only the
   generic encoding format is described here.

2.  Use of the Proxy Field in Join Messages

2.1  Proxy join

   Proxy fields are defined similar to the PIM source encoding type as
   defined in [I-D.ietf-pim-sm-v2-new].  A source address without any
   additional TLV's should be processed identically to a source address
   in the default source encoding.

   Multiple TLV's from the same or different type are permitted in a
   single source address in any order.

2.2  Transitive proxies

   It may be desired to have routers that understand the generic proxy
   format, forward the proxies regardless if they understand the TLV's
   encoded in the proxy not.  For this the first bit in the Type field
   is reserved.  If this bit is set then the TLV is forwarded upstream
   in case the router does not understand that type.

2.3  Proxy Hello Option

   A new PIM source type has been defined to include the Proxy field.
   This source type is included in a normal PIM Join.  Each router on a
   connected network needs to be able to understand and parse the Join
   message.  Therefore we include a new PIM hello option to advertise
   our capability to parse and process the new source type.  We can only
   send a PIM Join which includes a Proxy if ALL routers on the network
   support the new option.  (Even a router which is not the upstream
   neighbor must be able parse the packet in order to do Join
   suppression or overriding.) Option value TBD.

2.4  Conflicting Proxies

   It's possible that a router receives conflicting proxy information
   from different downstream routers.  See Figure 2.






Boers, et al.            Expires August 5, 2005                 [Page 3]


Internet-Draft            The PIM Proxy format             february 2005


       ( Edge A1 )            ( Edge B1 )---- [R1]
      /           \          /
     /             \        /
   [S]              ( Core )
     \             /        \
      \           /          \
       ( Edge A2 )            ( Edge B2 )---- [R2]


        Figure 2

   There are 2 receivers for the same group connected to Edge B1 and B2.
   Suppose that edge router B1 prefers A1 as the exit point and B2
   prefers A2 as exit point to reach the source S.  If both Edge B1 and
   B2 send a Join including a Proxy to prefer their exit router in the
   network and they cross the same core router, the core router will get
   conflicting proxy information for the source.  If this happens we use
   the Proxy from the PIM adjacency with the numerically smallest IP
   address.  The Proxies from other sending routers may be kept around
   in case the best Proxy gets pruned or expires, we are able to
   immediately use the second best Proxy and converge quickly without
   waiting for the next periodic update.  If a TLV has its own
   definition for conflict resolution is is preferred over the conflict
   resolution above.

2.5  Proxy Convergence

   A Proxy is included in a PIM Join message together with the source
   information.  If the Proxy for this source is changed, we trigger a
   new PIM Join message to the upstream router.  This causes the new
   Proxy to be propagated.  This new Proxy implicitly removes the old
   Proxy upstream.  If processing the new Proxy results in a change in
   the distribution tree, a PIM Prune message may be sent.  This PIM
   Prune does not need to carry any Proxy, the sender of the prune and
   the source and group information is enough to identify the entry.
   The proxy information is removed immediately and possibly a new proxy
   is chosen from the database if available.

2.6  Multiple Proxies

   A PIM Join can contain multiple Proxies.  The Proxies are encoded as
   TLVs associated with a new PIM source type in the PIM message.  When
   a PIM Join with multiple Proxies is received, the first Proxy is
   processed, and the action taken depends upon the Proxy type.  This
   may or may not result in the processing of the next Proxy.  Proxies
   not processed are passed upstream unchanged.





Boers, et al.            Expires August 5, 2005                 [Page 4]


Internet-Draft            The PIM Proxy format             february 2005


3.  PIM Proxy packet format

3.1  PIM Join packet format

   There is no space in the default PIM source encoding to include a
   Proxy field.  Therefore we introduce a new source encoding type.  The
   proxies are formatted as TLV's.  The new Encoded source address looks
   like this:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Addr Family   | Encoding Type | TLV #   |S|W|R|  Mask Len     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|    Type     | Length        | Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
   |F|    Type     | Length        | Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
           .                    .                     .
           .                    .                     .

   TLV # gives the number of TLV's that are included with this source.
   With the 5 bits we can include a maximum of 31 TLV's

   F bit, Forward Unknown TLV bit.  If this bit is set the TLV is
   forwarded regardless if the router understands the Type.

   Type field of the TLV is 7 bits.

   Length field of the TLV is 1 byte.

   The other fields are the same as described in the PIM spec.
   [I-D.ietf-pim-sm-v2-new].

   The source TLV encoding type: TBD.

3.2  PIM Proxy Hello option

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OptionType = XX          |      OptionLength = 0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option type: TBD.





Boers, et al.            Expires August 5, 2005                 [Page 5]


Internet-Draft            The PIM Proxy format             february 2005


4.  Acknowledgments

   The authors would like to thank James Lingard for his comments on
   this topic.

5.  References

5.1  Normative References

   [I-D.ietf-pim-sm-v2-new]
              Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode PIM-SM):
              Protocol Specification  (Revised)",
              Internet-Draft draft-ietf-pim-sm-v2-new-11, October 2004.

5.2  Informative References


Authors' Addresses

   Arjen Boers
   Cisco Systems, Inc.
   Avda. Diagonal, 682
   Barcelona  08034
   Spain

   Email: aboers@cisco.com


   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   Belgium

   Email: ice@cisco.com


   Eric Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, Ma  01719

   Email: erosen@cisco.com







Boers, et al.            Expires August 5, 2005                 [Page 6]


Internet-Draft            The PIM Proxy format             february 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




Boers, et al.            Expires August 5, 2005                 [Page 7]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/