tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6513

 
 
 

Multicast in MPLS/BGP IP VPNs

Part 5 of 5, p. 75 to 88
Prev RFC Part

 


prevText      Top      Up      ToC       Page 75 
12.  Encapsulations

   The BGP-based auto-discovery procedures will ensure that the PEs in a
   single MVPN only use tunnels that they can all support, and for a
   given kind of tunnel, that they only use encapsulations that they can
   all support.

12.1.  Encapsulations for Single PMSI per P-Tunnel

12.1.1.  Encapsulation in GRE

   GRE encapsulation can be used for any PMSI that is instantiated by a
   mesh of unicast P-tunnels, as well as for any PMSI that is
   instantiated by one or more PIM P-tunnels of any sort.

      Packets received        Packets in transit      Packets forwarded
      at the ingress PE       in the service          by the egress PEs
                              provider network

                           +---------------+
                           |  P-IP Header  |
                           +---------------+
                           |      GRE      |
   ++=============++       ++=============++       ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++       ++=============++       ++=============++

Top      Up      ToC       Page 76 
   The IP Protocol Number field in the P-IP header MUST be set to 47.
   The Protocol Type field of the GRE header is set to either 0x800 or
   0x86dd, depending on whether the C-IP header is IPv4 or IPv6,
   respectively.

   When an encapsulated packet is transmitted by a particular PE, the
   source IP address in the P-IP header must be the same address that
   the PE uses to identify itself in the VRF Route Import Extended
   Communities that it attaches to any of VPN-IP routes eligible for UMH
   determination that it advertises via BGP (see Section 5.1).

   If the PMSI is instantiated by a PIM tree, the destination IP address
   in the P-IP header is the group P-address associated with that tree.
   The GRE key field value is omitted.

   If the PMSI is instantiated by unicast P-tunnels, the destination IP
   address is the address of the destination PE, and the optional GRE
   key field is used to identify a particular MVPN.  In this case, each
   PE would have to advertise a key field value for each MVPN; each PE
   would assign the key field value that it expects to receive.

   [RFC2784] specifies an optional GRE checksum and [RFC2890] specifies
   an optional GRE sequence number fields.

   The GRE sequence number field is not needed because the transport
   layer services for the original application will be provided by the
   C-IP header.

   The use of the GRE checksum field must follow [RFC2784].

   To facilitate high speed implementation, this document recommends
   that the ingress PE routers encapsulate VPN packets without setting
   the checksum or sequence fields.

12.1.2.  Encapsulation in IP

   IP-in-IP [RFC2003] is also a viable option.  The following diagram
   shows the progression of the packet as it enters and leaves the
   service provider network.

Top      Up      ToC       Page 77 
   Packets received        Packets in transit      Packets forwarded
   at the ingress PE       in the service          by the egress PEs
                           provider network

                           +---------------+
                           |  P-IP Header  |
   ++=============++       ++=============++       ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++       ++=============++       ++=============++

   When the P-IP header is an IPv4 header, its Protocol Number field is
   set to either 4 or 41, depending on whether the C-IP header is an
   IPv4 header or an IPv6 header, respectively.

   When the P-IP header is an IPv6 header, its Next Header field is set
   to either 4 or 41, depending on whether the C-IP header is an IPv4
   header or an IPv6 header, respectively.

   When an encapsulated packet is transmitted by a particular PE, the
   source IP address in the P-IP header must be the same address that
   the PE uses to identify itself in the VRF Route Import Extended
   Communities that it attaches to any of VPN-IP routes eligible for UMH
   determination that it advertises via BGP (see Section 5.1).

12.1.3.  Encapsulation in MPLS

   If the PMSI is instantiated as a P2MP MPLS LSP or a MP2MP LSP, MPLS
   encapsulation is used.  Penultimate-hop-popping MUST be disabled for
   the LSP.

   If other methods of assigning MPLS labels to multicast distribution
   trees are in use, these multicast distribution trees may be used as
   appropriate to instantiate PMSIs, and appropriate additional MPLS
   encapsulation procedures may be used.

   Packets received        Packets in transit      Packets forwarded
   at the ingress PE       in the service          by the egress PEs
                           provider network

                           +---------------+
                           | P-MPLS Header |
   ++=============++       ++=============++       ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++       ++=============++       ++=============++

Top      Up      ToC       Page 78 
12.2.  Encapsulations for Multiple PMSIs per P-Tunnel

   The encapsulations for transmitting multicast data messages when
   there are multiple PMSIs per P-tunnel are based on the encapsulation
   for a single PMSI per P-tunnel, but with an MPLS label used for
   demultiplexing.

   The label is upstream-assigned and distributed via BGP as specified
   in Section 4.  The label must enable the receiver to select the
   proper VRF and may enable the receiver to select a particular
   multicast routing entry within that VRF.

12.2.1.  Encapsulation in GRE

   Rather than the IP-in-GRE encapsulation discussed in Section 12.1.1,
   we use the MPLS-in-GRE encapsulation.  This is specified in
   [MPLS-IP].  The GRE protocol type MUST be set to 0x8847.  (The reason
   for using the unicast rather than the multicast value is specified in
   [MPLS-MCAST-ENCAPS]).

12.2.2.  Encapsulation in IP

   Rather than the IP-in-IP encapsulation discussed in Section 12.1.2,
   we use the MPLS-in-IP encapsulation.  This is specified in [MPLS-IP].
   The IP protocol number field MUST be set to the value identifying the
   payload as an MPLS unicast packet.  (There is no "MPLS multicast
   packet" protocol number.)

12.3.  Encapsulations Identifying a Distinguished PE

12.3.1.  For MP2MP LSP P-Tunnels

   As discussed in Section 9, if a multicast data packet is traveling on
   a unidirectional C-tree, it is highly desirable for the PE that
   receives the packet from a PMSI to be able to determine the identity
   of the PE that transmitted the data packet onto the PMSI.  The
   encapsulations of the previous sections all provide this information,
   except in one case.  If a PMSI is being instantiated by an MP2MP LSP,
   then the encapsulations discussed so far do not allow one to
   determine the identity of the PE that transmitted the packet onto the
   PMSI.

   Therefore, when a packet traveling on a unidirectional C-tree is
   traveling on a MP2MP LSP P-tunnel, it MUST carry, as its second
   label, a label that has been bound to the packet's ingress PE.  This
   label is an upstream-assigned label that the LSP's root node has
   bound to the ingress PE and has distributed via the PE Distinguisher

Top      Up      ToC       Page 79 
   Labels attribute of a PMSI A-D route (see Section 4).  This label
   will appear immediately beneath the labels that are discussed in
   Sections 12.1.3 and 12.2.

   A full specification of the procedures for advertising and for using
   the PE Distinguisher Labels attribute in this case is outside the
   scope of this document.

12.3.2.  For Support of PIM-BIDIR C-Groups

   As was discussed in Section 11, when a packet belongs to a PIM-BIDIR
   multicast group, the set of PEs of that packet's VPN can be
   partitioned into a number of subsets, where exactly one PE in each
   partition is the Upstream PE for that partition.  When such packets
   are transmitted on a PMSI, unless the procedures of Section 11.2.3
   are being used, it is necessary for the packet to carry information
   identifying a particular partition.  This is done by having the
   packet carry the PE Distinguisher Label corresponding to the Upstream
   PE of one partition.  For a particular P-tunnel, this label will have
   been advertised by the node that is the root of that P-tunnel.  (A
   full specification of the procedures for advertising PE Distinguisher
   Labels is out of the scope of this document.)

   This label needs to be used whenever a packet belongs to a PIM-BIDIR
   C-group, no matter what encapsulation is used by the P-tunnel.
   Hence, the encapsulations of Section 12.2 MUST be used.  If the
   P-tunnel contains only one PMSI, the PE label replaces the label
   discussed in Section 12.2.  If the P-tunnel contains multiple PMSIs,
   the PE label follows the label discussed in Section 12.2.

   In general, PE Distinguisher Labels can be carried if the
   encapsulation is MPLS, MPLS-in-IP, or MPLS-in-GRE.  However,
   procedures for advertising and using PE Distinguisher Labels when the
   encapsulation is LDP-based MP2P MPLS is outside the scope of this
   specification.

12.4.  General Considerations for IP and GRE Encapsulations

   These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations.

12.4.1.  MTU (Maximum Transmission Unit)

   It is the responsibility of the originator of a C-packet to ensure
   that the packet is small enough to reach all of its destinations,
   even when it is encapsulated within IP or GRE.

Top      Up      ToC       Page 80 
   When a packet is encapsulated in IP or GRE, the router that does the
   encapsulation MUST set the DF bit in the outer header.  This ensures
   that the decapsulating router will not need to reassemble the
   encapsulating packets before performing decapsulation.

   In some cases, the encapsulating router may know that a particular
   C-packet is too large to reach its destinations.  Procedures by which
   it may know this are outside the scope of the current document.
   However, if this is known, then:

     - If the DF bit is set in the IP header of a C-packet that is known
       to be too large, the router will discard the C-packet as being
       "too large" and follow normal IP procedures (which may require
       the return of an ICMP message to the source).

     - If the DF bit is not set in the IP header of a C-packet that is
       known to be too large, the router MAY fragment the packet before
       encapsulating it and then encapsulate each fragment separately.
       Alternatively, the router MAY discard the packet.

   If the router discards a packet as too large, it should maintain
   Operations, Administration, and Maintenance (OAM) information related
   to this behavior, allowing the operator to properly troubleshoot the
   issue.

   Note that if the entire path of the P-tunnel does not support an MTU
   that is large enough to carry the a particular encapsulated C-packet,
   and if the encapsulating router does not do fragmentation, then the
   customer will not receive the expected connectivity.

12.4.2.  TTL (Time to Live)

   The ingress PE should not copy the TTL field from the payload IP
   header received from a CE router to the delivery IP or MPLS header.
   The setting of the TTL of the delivery header is determined by the
   local policy of the ingress PE router.

12.4.3.  Avoiding Conflict with Internet Multicast

   If the SP is providing Internet multicast, distinct from its VPN
   multicast services, and using PIM based P-multicast trees, it must
   ensure that the group P-addresses that it used in support of MVPN
   services are distinct from any of the group addresses of the Internet
   multicasts it supports.  This is best done by using administratively
   scoped addresses [ADMIN-ADDR].

   The group C-addresses need not be distinct from either the group
   P-addresses or the Internet multicast addresses.

Top      Up      ToC       Page 81 
12.5.  Differentiated Services

   The setting of the DS (Differentiated Services) field in the delivery
   IP header should follow the guidelines outlined in [RFC2983].
   Setting the Traffic Class field [RFC5462] in the delivery MPLS header
   should follow the guidelines in [RFC3270].  An SP may also choose to
   deploy any of additional Differentiated Services mechanisms that the
   PE routers support for the encapsulation in use.  Note that the type
   of encapsulation determines the set of Differentiated Services
   mechanisms that may be deployed.

13.  Security Considerations

   This document describes an extension to the procedures of [RFC4364],
   and hence shares the security considerations described in [RFC4364]
   and [RFC4365].


   When GRE encapsulation is used, the security considerations of
   [MPLS-IP] are also relevant.  Additionally, the security
   considerations of [RFC4797] are relevant as it discusses implications
   on packet spoofing in the context of BGP/MPLS IP VPNs.

   The security considerations of [MPLS-HDR] apply when MPLS
   encapsulation is used.

   This document makes use of a number of control protocols: PIM
   [PIM-SM], BGP [MVPN-BGP], mLDP [MLDP], and RSVP-TE [RSVP-P2MP].
   Security considerations relevant to each protocol are discussed in
   the respective protocol specifications.

   If one uses the UDP-based protocol for switching to S-PMSI (as
   specified in Section 7.4.2), then an S-PMSI Join message (i.e., a UDP
   packet with destination port 3232 and destination address ALL-PIM-
   ROUTERS) that is not received over a PMSI (e.g., one received
   directly from a CE router) is an illegal packet and MUST be dropped.

   The various procedures for P-tunnel construction have security issues
   that are specific to the way that the P-tunnels are used in this
   document.  When P-tunnels are constructed via such techniques as PIM,
   mLDP, or RSVP-TE, each P or PE router receiving a control message
   MUST ensure that the control message comes from another P or PE
   router, not from a CE router.  (Interpreting an mLDP or PIM or RSVP-
   TE control message from a CE router as referring to a P-tunnel would
   be a bug.)

   A PE MUST NOT accept BGP routes of the MCAST-VPN address family from
   a CE.

Top      Up      ToC       Page 82 
   If BGP is used as a CE-PE routing protocol, then when a PE receives
   an IP route from a CE, if this route carries the VRF Route Import
   Extended Community, the PE MUST remove this Community from the route
   before turning it into a VPN-IP route.  Routes that a PE advertises
   to a CE MUST NOT carry the VRF Route Import Extended Community.

   An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE
   control message that attempts to extend a P-tunnel from one SP's
   domain into another SP's domain.  This is perfectly valid if there is
   an agreement between the SPs to jointly provide an MVPN service.  In
   the absence of such an agreement, however, this could be an
   illegitimate attempt to intercept data packets.  By default, an ASBR
   MUST NOT allow P-tunnels to extend beyond AS boundaries.  However, it
   MUST be possible to configure an ASBR to allow this on a specified
   set of interfaces.

   Many of the procedures in this document cause the SP network to
   create and maintain an amount of state that is proportional to
   customer multicast activity.  If the amount of customer multicast
   activity exceeds expectations, this can potentially cause P and PE
   routers to maintain an unexpectedly large amount of state, which may
   cause control and/or data plane overload.  To protect against this
   situation, an implementation should provide ways for the SP to bound
   the amount of state it devotes to the handling of customer multicast
   activity.

   In particular, an implementation SHOULD provide mechanisms that allow
   an SP to place limitations on the following:

     - total number of (C-*,C-G) and/or (C-S,C-G) states per VRF

     - total number of P-tunnels per VRF used for S-PMSIs

     - total number of P-tunnels traversing a given P router

   A PE implementation MAY also provide mechanisms that allow an SP to
   limit the rate of change of various MVPN-related states on PEs, as
   well as the rate at which MVPN-related control messages may be
   received by a PE from the CEs and/or sent from the PE to other PEs.

   An implementation that provides the procedures specified in Sections
   10.1 or 10.2 MUST provide the capability to impose an upper bound on
   the number of Source Active A-D routes generated and on how
   frequently they may be originated.  This MUST be provided on a per-
   PE, per-MVPN granularity.

Top      Up      ToC       Page 83 
   Lack of the mechanisms that allow an SP to limit the rate of change
   of various MVPN-related states on PEs, as well as the rate at which
   MVPN-related control messages may be received by a PE from the CEs
   and/or sent from the PE to other PEs may result in the control plane
   overload on the PE, which in turn would adversely impact all the
   customers connected to that PE, as well as to other PEs.

   See also the Security Considerations section of [MVPN-BGP].

14.  IANA Considerations

   Section 7.4.2 defines the "S-PMSI Join message", which is carried in
   a UDP datagram whose port number is 3232.  This port number had
   already been assigned by IANA to "MDT port".  The reference has been
   updated to this document.

   IANA has created a registry for the "S-PMSI Join message Type Field".
   Assignments are to be made according to the policy "IETF Review" as
   defined in [RFC5226].  The value 1 has been registered with a
   reference to this document.  The description reads "PIM IPv4 S-PMSI
   (unaggregated)".

   [PIM-ATTRIB] establishes a registry for "PIM Join attribute Types".
   IANA has assigned the value 1 to the "MVPN Join Attribute" with a
   reference to this document.

   IANA has assigned SAFI 129 to "Multicast for BGP/MPLS IP Virtual
   Private Networks (VPNs)" with a reference to this document and
   [MVPN-BGP].

15.  Acknowledgments

   Significant contributions were made Arjen Boers, Toerless Eckert,
   Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Giuliano, Shankar
   Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony
   Speakman, Dan Tappan.

Top      Up      ToC       Page 84 
16. References

16.1.  Normative References

   [MLDP]        Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and
                 B. Thomas, "Label Distribution Protocol Extensions for
                 Point-to-Multipoint and Multipoint-to-Multipoint Label
                 Switched Paths", RFC 6388, November 2011.

   [MPLS-HDR]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                 Encoding", RFC 3032, January 2001.

   [MPLS-IP]     Worster, T., Rekhter, Y., and E. Rosen, Ed.,
                 "Encapsulating MPLS in IP or Generic Routing
                 Encapsulation (GRE)", RFC 4023, March 2005.

   [MPLS-MCAST-ENCAPS]
                 Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y.
                 Rekhter, "MPLS Multicast Encapsulations", RFC 5332,
                 August 2008.

   [MPLS-UPSTREAM-LABEL]
                 Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
                 Label Assignment and Context-Specific Label Space", RFC
                 5331, August 2008.

   [MVPN-BGP]    Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter,
                 "BGP Encodings and Procedures for Multicast in MPLS/BGP
                 IP VPNs", RFC 6514, February 2012.

   [OSPF]        Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
                 1998.

   [OSPF-MT]     Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
                 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
                 RFC 4915, June 2007.

   [PIM-ATTRIB]  Boers, A., Wijnands, I., and E. Rosen, "The Protocol
                 Independent Multicast (PIM) Join Attribute Format", RFC
                 5384, November 2008.

   [PIM-SM]      Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
                 "Protocol Independent Multicast - Sparse Mode (PIM-SM):
                 Protocol Specification (Revised)", RFC 4601, August
                 2006.

Top      Up      ToC       Page 85 
   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4364]     Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
                 Networks (VPNs)", RFC 4364, February 2006.

   [RFC4659]     De Clercq, J., Ooms, D., Carugi, M., and F. Le
                 Faucheur, "BGP-MPLS IP Virtual Private Network (VPN)
                 Extension for IPv6 VPN", RFC 4659, September 2006.

   [RFC5462]     Andersson, L. and R. Asati, "Multiprotocol Label
                 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
                 to "Traffic Class" Field", RFC 5462, February 2009.

   [RSVP-OOB]    Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
                 Hop Popping Behavior and Out-of-Band Mapping for RSVP-
                 TE Label Switched Paths", RFC 6511, February 2012.

   [RSVP-P2MP]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
                 Yasukawa, Ed., "Extensions to Resource Reservation
                 Protocol - Traffic Engineering (RSVP-TE) for Point-to-
                 Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
                 May 2007.

16.2.  Informative References

   [ADMIN-ADDR]  Meyer, D., "Administratively Scoped IP Multicast", BCP
                 23, RFC 2365, July 1998.

   [BIDIR-PIM]   Handley, M., Kouvelas, I., Speakman, T., and L.
                 Vicisano, "Bidirectional Protocol Independent Multicast
                 (BIDIR-PIM)", RFC 5015, October 2007.

   [BSR]         Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
                 "Bootstrap Router (BSR) Mechanism for Protocol
                 Independent Multicast (PIM)", RFC 5059, January 2008.

   [MVPN-REQ]    Morin, T., Ed., "Requirements for Multicast in Layer 3
                 Provider-Provisioned Virtual Private Networks
                 (PPVPNs)", RFC 4834, April 2007.

   [RFC2003]     Perkins, C., "IP Encapsulation within IP", RFC 2003,
                 October 1996.

   [RFC2784]     Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                 Traina, "Generic Routing Encapsulation (GRE)", RFC
                 2784, March 2000.

Top      Up      ToC       Page 86 
   [RFC2890]     Dommety, G., "Key and Sequence Number Extensions to
                 GRE", RFC 2890, September 2000.

   [RFC2983]     Black, D., "Differentiated Services and Tunnels", RFC
                 2983, October 2000.

   [RFC3270]     Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                 Vaananen, P., Krishnan, R., Cheval, P., and J.
                 Heinanen, "Multi-Protocol Label Switching (MPLS)
                 Support of Differentiated Services", RFC 3270, May
                 2002.

   [RFC3618]     Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
                 Discovery Protocol (MSDP)", RFC 3618, October 2003.

   [RFC4365]     Rosen, E., "Applicability Statement for BGP/MPLS IP
                 Virtual Private Networks (VPNs)", RFC 4365, February
                 2006.

   [RFC4607]     Holbrook, H. and B. Cain, "Source-Specific Multicast
                 for IP", RFC 4607, August 2006.

   [RFC4797]     Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider
                 Edge to Provider Edge (PE-PE) Generic Routing
                 Encapsulation (GRE) or IP in BGP/MPLS IP Virtual
                 Private Networks", RFC 4797, January 2007.

   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 5226, May 2008.

Top      Up      ToC       Page 87 
Contributing Authors

   Sarveshwar Bandi
   Motorola
   Vanenburg IT park, Madhapur,
   Hyderabad, India
   EMail: sarvesh@motorola.com

   Yiqun Cai
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134
   EMail: ycai@cisco.com

   Thomas Morin
   France Telecom R & D
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   EMail: thomas.morin@francetelecom.com

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   EMail: yakov@juniper.net

   IJsbrand Wijnands
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134
   EMail: ice@cisco.com

   Seisho Yasukawa
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585,
   Japan
   Phone: +81 422 59 4769
   EMail: yasukawa.seisho@lab.ntt.co.jp

Top      Up      ToC       Page 88 
Editors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA, 01719
   EMail: erosen@cisco.com

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   EMail: raggarwa_1@yahoo.com