rfc3251.txt

RFC 的详细文档！

   (voltage) switching as electricity flows through the distribution
   network.  The configuration of switching elements in the distribution
   network is done through RSVP-TE to provide electricity on demand.

   We admit that the above description is vague and sounds crazy.  The
   example below tries to add more (useless) details, without removing
   any doubts the reader might have about the feasibility of this
   proposal:

   Example: Turning on a Lamp

   It is assumed that the lamp is controlled by an intelligent device
   (e.g, a (light) switch with an MPLampS control plane).  Turning the
   lamp on causes the switch to issue an RSVP-TE request (a PATH message
   with new objects) for the electricity flow.  This PATH message
   traverses across the network to the ES.  The RESV message issued in
   return sets up the label mappings in LSRs.  Finally, electricity
   starts flowing along the path established.  It is expected that the
   entire process will be completed within a few seconds, thereby giving
   the MPLampS architecture a distinct advantage over lighting a candle
   with a damp match stick.






Rajagopalan                  Informational                      [Page 5]

RFC 3251                  Electricity over IP               1 April 2002


7.2  Overlay vs Peer Models

   As noted before, there are two control plane models to be considered.
   Under the overlay model, the lamps and the distribution network
   utilize distinct control planes.  Under the peer model, a single
   control plane is used.  A number of arguments can be made for one
   model versus the other, and these will be covered in the upcoming
   framework document.  We merely observe here that it is the lamp
   vendors who prefer the peer model against the better judgement of the
   LSR vendors.  We, however, want to please both camps regardless of
   the usefulness of either model.  We therefore note here that MPLampS
   supports both models and also migration scenarios from overlay to
   peer.

7.3 Routing in the Core Network

   The above description of the hierarchical distribution system
   immediately opens up the possibility of applying OSPF and ISIS with
   suitable extensions.  The readers may rest assured that we are
   already working on such concepts as voltage bundling, multi-area
   tariff extensions, insulated LSAs, etc.  Future documents will
   describe the details.

7.4 Voltage Protected Networks (VPNs)

   VPNs allow a customer with multiple sites to get guaranteed
   electricity supply with negligible voltage fluctuations due to
   interference from other customers.  Indeed, some may argue that the
   entire MPLampS architecture may be trashed if not for the possibility
   of doing VPNs.  Whatever be the case, VPNs are a hot topic today and
   the readers are forewarned that we have every intention of writing
   several documents on this.  Specifically, BGP-support for VPNs is an
   area we're presently eyeing with interest.

8. Multicast

   It has been observed that there is a strong spatial and temporal
   locality in electricity demand.  ITU Study Group 55 has studied this
   phenomenon for over a decade and has issued a preliminary report.
   This report states that when a lamp is turned on in one house, it is
   usually the case that lamps are turned on in neighboring houses at
   around the same time (usually at dusk) [3].  This observation has a
   serious implication on the scalability of the signaling mechanism.
   Specifically, the distribution network must be able to handle tens of
   thousands of requests all at once.  The signaling load can be reduced
   if multicast delivery is used.  Briefly, a request for electricity is
   not sent from the lamp all the way to an ES, but is handled by the
   first LSR that is already in the path to another lamp.



Rajagopalan                  Informational                      [Page 6]

RFC 3251                  Electricity over IP               1 April 2002


   Support for this requires the application of multicast routing
   protocols together with RSVP-TE shared reservation styles and the
   development of MPLampS multicast forwarding mode.  We are currently
   studying the following multicast routing protocol:

   o DVMRP: Discrete Voltage Multicast Routing Protocol - this protocol
   works over existing voltage routing protocols but the danger here is
   that electricity is delivered to all lamps when any one lamp is
   turned on.  Indeed, the switching semantics gets annoying - all lamps
   get turned on periodically and those not needed must be switched off
   each time manually.

   Other protocols we will eventually consider are Current-Based Tree
   (CBT) and Practically Irrelevant Multicast (PIM).  An issue we are
   greatly interested in is multicast scope: we would like support for
   distributing electricity with varying scope, from lamps within a
   single Christmas tree to those in entire cities.  Needless to say, we
   will write many detailed documents on these topics as time
   progresses.

9. Security Considerations

   This document MUST be secured in a locked cabinet to prevent it from
   being disposed off with the trash.

10. Summary

   This document described the motivation and high level concepts behind
   Mostly Pointless Lamp Switching (MPLampS), an architecture for
   electricity distribution over IP.  MPLampS utilizes DVE (discrete
   voltage encoding), and an MPLS control plane in the distribution
   network.  Since the aim of this document is to be a high-visibility
   place-holder, we did not get into many details of MPLampS.  Numerous
   future documents, unfortunately, will attempt to provide these
   details.

11. References

   1. A. Malis, et al., "SONET/SDH Circuit Emulation Service Over MPLS
      (CEM) Encapsulation", Internet Draft, Work in Progress.

   2. International Tarriffed Utilities association draft standard, ITU
      G.110/230V, "Discrete Voltage Encoding", March, 1999.

   3. International Tarriffed Utilities association technical report,
      ITU (SG-55) TR-432-2000, "Empirical Models for Energy
      Utilization", September, 2000.




Rajagopalan                  Informational                      [Page 7]

RFC 3251                  Electricity over IP               1 April 2002


12. Disclaimer

   The opinions expressed in this document are solely the author's.
   Company's opinions, as always, are proprietary and confidential and
   may be obtained under appropriate NDAs.

13. Author's Address

   Bala Rajagopalan
   Tellium, Inc.
   2 Crescent Place
   Ocean Port, NJ 07757
   Phone: [phone]
   EMail: [e-mail]





































Rajagopalan                  Informational                      [Page 8]

RFC 3251                  Electricity over IP               1 April 2002


14. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.



















Rajagopalan                  Informational                      [Page 9]