TSVWG F. Le Faucheur Internet-Draft Cisco Intended status: Standards Track J. Manner Expires: June 16, 2008 University of Helsinki A. Narayanan Cisco A. Guillou Neuf H. Malik Bharti December 14, 2007 RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-04.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
https://www.doczj.com/doc/346658590.html,/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
https://www.doczj.com/doc/346658590.html,/shadow.html.
This Internet-Draft will expire on June 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Le Faucheur, et al. Expires June 16, 2008 [Page 1]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 Abstract
RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
thereby performing RSVP signaling on behalf of the receiver. This
allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy
approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these
extensions.
Le Faucheur, et al. Expires June 16, 2008 [Page 2]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 3.1. Sender Notification via PathErr Message . . . . . . . . . 10 3.1.1. Composition of SESSION and
4. Use of PathErr by Regular Receivers . . . . . . . . . 15
3.2. Sender Notification via Notify Message . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Le Faucheur, et al. Expires June 16, 2008 [Page 3]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 1. Introduction
Guaranteed QoS for some applications with tight Qos requirements may be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP specified in [RFC2205]. RSVP does not require that all intermediate nodes support RSVP, but it assumes that both the sender and the
receiver of the data flow support RSVP. However, there are
environments where it would be useful to be able to reserve resources for a flow (at least a subset of the flow path) even when the sender or the receiver (or both) is not RSVP-capable.
Since both the data sender and receiver may be unaware of RSVP, there are two distinct RSVP Proxy cases. In the first case, an entity in
the network must operate on behalf of the data sender, generate RSVP Path messages, and eventually receive, process and sink Resv
messages. We refer to this entity as the RSVP Sender Proxy. In the second case, an entity in the network must receive Path messages sent by a data sender (or by an RSVP Sender Proxy), and reply to those
with Resv messages generated on behalf of the data receiver(s). We
refer to this entity as the RSVP Receiver Proxy.
RSVP Proxy approaches are presented in
[I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also
discusses, for each approach, how the reservations controlled by the RSVP Proxy can be synchronised with the application requirements
(e.g. when to establish, maintain and tear down the RSVP reservation to satisfy application requirements).
One RSVP Proxy approach is referred to as the Path-Triggered RSVP
Receiver Proxy approach. With this approach, the RSVP Receiver Proxy uses the RSVP Path messages generated by the sender (or RSVP Sender
Proxy) as the cue for establishing the RSVP reservation on behalf of the non-RSVP-capable receiver. The RSVP Receiver Proxy is
effectively acting as an intermediary making reservations (on behalf of the receiver) under the sender’s control (or RSVP Sender Proxy’s
control). This changes somewhat the usual RSVP reservation model
where reservations are normally controlled by receivers. Such a
change greatly facilitates operations in the scenario of interest
here, which is where the receiver is not RSVP-capable. Indeed it
allows the RSVP Receiver Proxy to remain application unaware by
taking advantage of the application awareness and RSVP awareness of
the sender (or RSVP Sender Proxy).
Since the synchronisation between RSVP reservation and application
requirement is now effectively performed by the sender (or RSVP
Sender Proxy), it is important that the sender (or RSVP Sender Proxy) is aware of the reservation state. However, as conventional RSVP
Le Faucheur, et al. Expires June 16, 2008 [Page 4]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 assumes that the reservation is to be controlled by the receiver,
some notifications about reservation state (notably the error message sent in case of admission control rejection of the reservation) are
only sent towards the receiver and therefore, in our case, sunk by
the RSVP Receiver Proxy. This document specifies extension to RSVP
procedures allowing such notifications to be also conveyed towards
the sender. This facilitates synchronization by the sender (or RSVP Sender Proxy) between RSVP reservation and application requirements
in scenarios involving a Path-Triggered RSVP receiver Proxy.
This document discusses extension to facilitate operations in the
presence of an RSVP Receiver Proxy. As explicitly pointed out in the text above, those apply equally whether RSVP signaling is initiated
by a regular RSVP sender or by an RSVP Sender Proxy (with some means to synchronize reservation state with application level requirements that are outside the scope of this document). For readability, the
rest of this document discusses operation assuming a regular RSVP
sender; however, such operation is equally applicable where an RSVP
Sender Proxy is used to initiated RSVP signaling on behalf of a non- RSVP-capable sender.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Le Faucheur, et al. Expires June 16, 2008 [Page 5]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 2. Terminology
The following terminology is borrowed from
[I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the present document:
o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per [RFC2205]
o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of a receiver, the RSVP operations which would normally be
performed by an RSVP-capable receiver if end-to-end RSVP signaling was used. Note that while RSVP is used upstream of the RSVP
Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
Proxy.
o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a sender, the RSVP operations which would normally be performed by an RSVP-capable sender if end-to-end RSVP signaling was used.
Note that while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not used upstream of the RSVP Sender Proxy.
o Regular RSVP Router: an RSVP-capable router which is not behaving as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.
o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
Regular RSVP Router are all relative to one unidirectional flow.
A given router may act as the RSVP Receiver Proxy for a flow, as
the RSVP Sender Proxy for another flow and as a Regular RSVP
router for yet another flow.
The following terminology is also used in the present document:
o Regular RSVP Sender: an RSVP-capable host behaving as the sender
for the considered flow and participating in RSVP signaling in
accordance with the sender behavior specified in [RFC2205].
o Regular RSVP Receiver: an RSVP-capable host behaving as the
receiver for the considered flow and participating in RSVP
signaling in accordance with the receiver behavior specified in
[RFC2205].
Le Faucheur, et al. Expires June 16, 2008 [Page 6]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 3. RSVP Extensions for Sender Notification
This section defines extensions to RSVP procedures allowing sender
notification of reservation failure. This facilitates
synchronization by the sender between RSVP reservation and
application requirements in scenarios involving a Path-Triggered RSVP Receiver Proxy.
As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the
Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be
configured to use receipt of a regular RSVP Path message as the
trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP
Path message, the RSVP Receiver Proxy:
1. establishes the RSVP Path state as per regular RSVP processing
2. identifies the downstream interface towards the receiver
3. sinks the Path message
4. behaves as if a Resv message (whose details are discussed below) was received on the downstream interface. This includes
performing admission control on the downstream interface,
establishing a Resv state (in case of successful admission
control) and forwarding the Resv message upstream, sending
periodic refreshes of the Resv message and tearing down the
reservation if the Path state is torn down.
Operation of the Path-Triggered Receiver Proxy in the case of a
successful reservation is illustrated in Figure 1.
Le Faucheur, et al. Expires June 16, 2008 [Page 7]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy |
|----------|
************************************************************>
===================RSVP===================>
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv--
|----| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP |----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 1: Successful Reservation
We observe that, in the case of successful reservation, conventional RSVP procedures ensure that the sender is notified of the successful reservation establishment. Thus, no extensions are required in the
presence of a Path-Triggered RSVP Receiver Proxy in the case of
successful reservation establishment.
However, in case of reservation failure, conventional RSVP procedures only ensure that the receiver (or the RSVP Receiver Proxy) is
notified of the reservation failure. Specifically, in case of an
admission control rejection on a regular RSVP router, a ResvErr
message is sent downstream towards the receiver. In the presence of an RSVP Receiver Proxy, if we simply follow conventional RSVP
procedures, this means that the RSVP Receiver Proxy is notified of
the reservation failure, but the sender is not. Operation of the
Path-Triggered RSVP Receiver Proxy in the case of an admission
control failure, assuming conventional RSVP procedures, is
illustrated in Figure 2.
Le Faucheur, et al. Expires June 16, 2008 [Page 8]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy |
|----------|
************************************************************>
===================RSVP===================>
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv--
-ResvErr-> -ResvErr->
|----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 2: Reservation Failure With Conventional RSVP
While the sender could infer reservation failure from the fact that
it has not received a Resv message after a certain time, there are
clear benefits in ensuring that the sender gets a prompt explicit
notification in case of reservation failure. This includes faster
end-user notification at application layer (e.g. busy signal), faster application level reaction (e.g. application level rerouting), as
well as faster release of application-level resources.
Section 3.1 defines a method which can be used to achieve sender
notification of reservation failure. A router implementation
claiming compliance with this document MUST support the method
defined in Section 3.1.
Section 3.2 defines another method which can be used to achieve
sender notification of reservation failure. A router implementation claiming compliance with this document MAY support the method defined in Section 3.2.
In a given network environment, a network administrator may elect to Le Faucheur, et al. Expires June 16, 2008 [Page 9]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 use the method defined in Section 3.1, or the method defined in
Section 3.2, or possibly combine the two.
3.1. Sender Notification via PathErr Message
With this method, the RSVP Receiver Proxy MUST generate a PathErr
message whenever the two following conditions are met:
1. The reservation establishment has failed (or the previously
established reservation has been torn down)
2. The RSVP Receiver Proxy determines that it cannot re-establish
the reservation (e.g. by adapting its reservation request in
reaction to the error code provided in the received ResvErr in
accordance with local policy)
Note that this notion of generating a PathErr message upstream in
order to notify the sender about a reservation failure is not
completely new. It is borrowed from [RFC3209] where it has been
introduced in order to achieve a similar requirement, which is to
allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end (i.e. the sender) of a failure to establish (or maintain) a TE Tunnel Label Switch Path.
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via PathErr
Message, is illustrated in Figure 3.
Le Faucheur, et al. Expires June 16, 2008 [Page 10]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy |
|----------|
************************************************************>
===================RSVP===================>
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv--
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
|----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 3: Reservation Failure With Sender Notification via PathErr
The role of this PathErr is to notify the sender that the reservation was not established or was torn down. This may be in the case of
receipt of a ResvErr, or because of local failure on the Receiver
Proxy. On receipt of a ResvErr, in all situations where the
reservation cannot be installed, the Receiver Proxy MUST generate a
PathErr towards the sender. For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would cause the
generation of a ResvErr (for example, CAC failure), the Receiver
Proxy MUST generate a PathErr towards the sender. The Receiver Proxy MAY additionally generate a PathErr upon local failures which would
not ordinarily cause generation of a ResvErr message, such as
described in Appendix B of [RFC2205].
The PathErr generated by the Receiver Proxy corresponds to the
sender(s) which triggered generation of Resv messages that failed.
For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a PathErr towards the (single) sender matching the failed reservation. Le Faucheur, et al. Expires June 16, 2008 [Page 11]
Internet-Draft RSVP Receiver Proxy Extensions December 2007 For Shared-Explicit (SE) style reservations, the Receiver Proxy sends the PathErr(s) towards the set of senders which triggered
reservations that failed. This may be a subset of senders sharing
the same reservation, in which case the remaining senders would have their reservation intact and would not receive a PathErr. In both
cases, the rules described in Section 3.1.8 of [RFC2205] for
generating flow descriptors in ResvErr messages, also apply for
generating sender descriptors in PathErr messages.
For Wildcard-Filter (WF) style reservations, it is not possible for
the receiver to know which sender caused the reservation failure.
Therefore, the procedures described in this section do not apply to
WF-style reservations.
The procedures described in this section apply to both unicast and
multicast sessions. However, for a multicast session, it is possible that reservation failure (e.g. admission control failure) in a node
close to a sender may cause ResvErr messages to be sent to a large
group of receivers. These receivers would, in turn, all send PathErr messages back to the same sender, which could cause a scalability
issue in some environments. From the perspective of the sender,
errors that prevent a reservation from being set up can be classified in two ways:
1. Errors which the sender can attempt to correct. The error code
for those errors should explicitly be communicated back to the
sender. An examples of this is "Class 1: Admission Control
Failure", because the sender could potentially resend a Path with smaller traffic parameters.
2. Errors which the sender has no control over. For these errors,
it is sufficient to notify the sender that the reservation was
not set up successfully. An example of this is "Class 13:
Unknown Object", because the sender has no control over the
objects inserted into the reservation by the Receiver Proxy.
The PathErr message generated by the Receiver Proxy has the same
format as regular PathErr messages defined in [RFC2205]. The
SESSION, ERROR_SPEC and sender descriptor are composed by the
Receiver Proxy as specified in the following subsections. The
Receiver Proxy MAY reflect back towards the sender in the PathErr any POLICY_DATA objects received in the ResvErr.
3.1.1. Composition of SESSION and
The Receiver Proxy MUST insert the SESSION object corresponding to
the failed reservation, into the PathErr. For Fixed-Filter (FF)
style reservations, the Receiver Proxy MUST insert a Le Faucheur, et al. Expires June 16, 2008 [Page 12] Internet-Draft RSVP Receiver Proxy Extensions December 2007 descriptor> corresponding to the failed reservation, into the PathErr. This is equal to the received by the Receiver Proxy. For Shared-Explicit (SE) style reservations, the Receiver Proxy MUST insert a corresponding to the sender triggering the failed reservation, into the PathErr. This is equal to the received by the Receiver Proxy. If multiple [RFC2205]. Each ResvErr would contain a matches a specific sender. The Receiver Proxy MUST generate a PathErr for each ResvErr received, towards the corresponding sender. 3.1.2. Composition of ERROR_SPEC The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into the PathErr as follows: 1. If the Receiver Proxy receives a ResvErr with any of these error codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy Control Failure" then the Receiver Proxy copies the error code and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC of the PathErr message. The error node in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with one of the above codes. 2. If the Receiver Proxy receives a ResvErr with any error code other than the ones listed in 1 above, it composes a new ERROR_SPEC with error code " section>: Unrecoverable Receiver Proxy Error". The error node in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with any error code except than those listed in 1 above, or if the Receiver Proxy generates a PathErr for a local error which ordinarily would not cause generation of a ResvErr. In some cases it may be predetermined that the PathErr will not reach the sender. For example, a node receiving a ResvErr with "Code 3: No Path for Resv", knows a priori that the PathErr message it generates cannot be forwarded by the same node which could not process the Resv. Nevertheless, the procedures above MUST be followed. For the error code " Considerations section>: Unrecoverable Receiver Proxy Error", the 16 bits of the Error Value field are: Le Faucheur, et al. Expires June 16, 2008 [Page 13] Internet-Draft RSVP Receiver Proxy Extensions December 2007 * hhhh hhhh llll llll where the bits are: * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored by the sender. * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) MUST be set by the Receiver Proxy to the value of the error code received in the ResvErr ERROR_SPEC (or, in case the Receiver Proxy generated the PathErr without having received a ResvErr, to the error code value that would have been included by the Receiver Proxy in the ERROR_SPEC in similar conditions if it was to generate a ResvErr). This error value MAY be used by the sender to further interpret the reason of the reservation failure. * hhhh hhhh = any other value: reserved. 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag set in the ERROR_SPEC, it MUST also set the InPlace flag in the ERROR_SPEC of the PathErr. 3.1.3. Use of Path_State_Removed Flag [RFC3473] defines an optional behavior whereby a node forwarding a PathErr message can remove the Path State associated with the PathErr message and indicate so by including the Path_State_Removed flag in the ERROR_SPEC object of the PathErr message. This can be used in some situations to expedite release of resources and minimise signaling load. This section discusses aspects of the use of the Path_State_Removed flag that are specific to the RSVP Receiver Proxy. In any other aspects, the Path_State_Removed flag operates as per [RFC3473]. By default, the RSVP Receiver Proxy MUST not include the Path_State_Removed flag in the ERROR_SPEC of the PathErr message. This ensures predictable operations in all environments including those where some RSVP routers do not understand the Path_State_Removed flag. Optionally, the RSVP Receiver Proxy MAY support an optional mode that can be activated by configuration whereby the RSVP Receiver Proxy includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr message and removes its local Path state. Where all routers on the path of a reservation support the Path_State_Removed flag, its use Le Faucheur, et al. Expires June 16, 2008 [Page 14] Internet-Draft RSVP Receiver Proxy Extensions December 2007 will indeed result in expedited resource release and reduced signaling. However, if there is one (or more) "old" router on the path of the reservation that does not support the Path_State_Removed flag, its use will actually result in slower resource release and increased signaling. This is because the Path_State_Removed flag will be propagated upstream by an "old" router (even if it does not understand it and does not tear its Path state). Thus, the sender will not send a Path Tear and the "old" router will only release its Path state through refresh time-out. A network administrator needs to keep these considerations in mind when deciding whether to activate the use of the Path_State_Removed flag on the RSVP Receiver Proxy. In a controlled environment where all routers are known to support the Path_State_Removed flag, its use can be safely activated on the RSVP Receiver Proxy. In other environments, the network administrator needs to assess whether the improvement achieved with some reservations outweighs the degradation experienced by other reservations. 3.1. 4. Use of PathErr by Regular Receivers Note that while this document specifies that an RSVP Receiver Proxy generates a PathErr upstream in case of reservation failure, this document does NOT propose that the same be done by regular receivers. In other words, this document does NOT propose to modify the behavior of regular receivers as currently specified in [RFC2205]. The rationale for this includes the following: o when the receiver is RSVP capable, the current receiver-driven model of [RFC2205] is fully applicable because the receiver can synchronise RSVP reservation state and application state (since it participates in both). The sender(s) needs not be aware of the RSVP reservation state. Thus, we can retain the benefits of receiver-driven operations which were explicitly sought by [RFC2205]. Quoting from it: " In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS". But even for the most simple single_sender/ single_receiver reservations, the current receiver-driven model reduces signaling load and per-hop RSVP processing by not sending any error message to the sender in case of CAC reject. o the motivation for adding sender error notification in case of receiver proxy lies in the fact that the actual receiver can no longer synchronize RSVP reservation with application state (since the receiver does not participate in RSVP signaling), while the sender can. This motivation does not apply in case of regular receiver. Le Faucheur, et al. Expires June 16, 2008 [Page 15] Internet-Draft RSVP Receiver Proxy Extensions December 2007 o there is a lot of existing code and deployed systems successfully working under the current [RFC2205] model in the absence of proxy today. The current behavior should not be changed for those unless there were a very strong motivation. 3.2. Sender Notification via Notify Message The OPTIONAL method for sender notification of reservation failure defined in this section aims at providing a more efficient method than the one defined in Section 3.1. Its objectives include : o allow the failure notification to be sent directly upstream to the sender by the router where the failure occurs (as opposed to first travelling downstream towards the Receiver Proxy and then travelling upstream from the Receiver Proxy to the sender, as effectively happens with the method defined in Section 3.1) o allow the failure notification to travel directly to the sender without hop-by-hop RSVP processing o ensure that such a notification is only sent to senders which are capable and willing to process it (i.e. to synchronize reservation status with application) o ensure that such a notification is only sent in case the receiver is not itself capable and willing to do the synchronisation with the application (i.e. because we are in the presence of a receiver proxy so that RSVP signaling is not visible to the receiver). Note, however, that such benefits come at the cost of : o a requirement for RSVP routers and senders to support the Notify messages and procedures defined in [RFC3473] o a requirement for senders to process Notify messages traveling upstream but conveying a downstream notification. [RFC3473] defines (in section "4.3 Notify Messages") the Notify message that provides a mechanism to inform non-adjacent nodes of events related to the RSVP reservation. The Notify message differs from the error messages defined in [RFC2205] (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. Notify messages are normally generated only after a Notify Request object has been received. This section discusses aspects of the use of the Notify message that are specific to the RSVP Receiver Proxy. In any other aspects, the Le Faucheur, et al. Expires June 16, 2008 [Page 16] Internet-Draft RSVP Receiver Proxy Extensions December 2007 Notify message operates as per [RFC3473]. In order to achieve sender notification of reservation failure in the context of the present document: o an RSVP sender interested in being notified of reservation failure MUST include a Notify Request object (containing the sender’s IP address) in the Path messages it generates o Upon receiving a Path message with a Notify Request object, the RSVP Receiver Proxy MUST include a Notify Request object in the Resv messages it generates. This Notify Request object MUST contain the address that was included in the Notify Request of the received Path message- a.k.a. the sender’s address- and not an address of the Receiver Proxy. As a result, as per existing Notify procedures, if an RSVP router detects an error relating to a Resv state (e.g. Admission Control rejection after IP reroute), the RSVP router will send a Notify message (conveying the Resv Err code) to the IP address contained in the Resv Notify Request object. Since this address has been set to the sender’s address by the Receiver Proxy, the Notify message is sent to the sender. Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via Notify Message, is illustrated in Figure 4. Le Faucheur, et al. Expires June 16, 2008 [Page 17] Internet-Draft RSVP Receiver Proxy Extensions December 2007 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy | |----------| ************************************************************> ===================RSVP===================> --Path*--> --Path*--> --Path*--> --Path*--> <--Resv*-- <--Resv*-- <------Notify------- -ResvErr-> -ResvErr-> |----| |----| *** | S | Sender | R | Receiver *r* regular RSVP |----| |----| *** router ***> media flow ==> segment of flow path protected by RSVP reservation Path* = Path message containing a Notify Request object with sender IP Address Resv* = Resv message containing a Notify Request object with sender IP address Notify = Notify message Figure 4: Reservation Failure With Sender Notification via Notify For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would cause the generation of a ResvErr (for example, CAC failure), the Receiver Proxy MUST generate a Notify towards the sender. The Receiver Proxy MAY additionally generate a Notify upon local failures which would not ordinarily cause generation of a ResvErr message, such as described in Appendix B of [RFC2205]. When the method of sender notification via Notify message is used, it is RECOMMENDED that the RSVP Receiver Proxy also issues sender Le Faucheur, et al. Expires June 16, 2008 [Page 18] Internet-Draft RSVP Receiver Proxy Extensions December 2007 notification via a PathErr message. This maximizes the chances that the notification reaches the sender in all situations (e.g. even if some RSVP routers do not support the Notify procedure, or if a Notify message gets dropped). However, for controlled environments (e.g. where all RSVP routers are known to support Notify procedures) and where it is desirable to minimize the volume of signaling, the RSVP Receiver Proxy MAY rely exclusively on sender notification via Notify message and thus not issue sender notification via PathErr message. Le Faucheur, et al. Expires June 16, 2008 [Page 19] Internet-Draft RSVP Receiver Proxy Extensions December 2007 4. Security Considerations To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] may be used. Those protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can be used to protect the RSVP reservations established using an RSVP receiver proxy in accordance with the present document. [RFC2747] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure key distribution can be used. However, existing key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve. The use of RSVP Authentication in parts of the network where there may be one or more IP hops in between two RSVP neighbors raises an additional challenge. This is because, with some RSVP messages such as a Path message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, say because of a routing change). Hence, the RSVP router may not know which security association to use when forwarding such a message. In that situation, one approach is to share the same RSVP Authentication shared key across all the RSVP routers of a part of the network where there may be RSVP neighbors with IP hops in between. For example, all the RSVP routers of an administrative domain (including the receiver proxys) could share the same RSVP Authentication key, while different per-neighbor keys could be used between any RSVP router pair straddling the boundary between two administrative domains that have agreed to use RSVP signaling. When the same RSVP Authentication shared key is to be shared among multiple RSVP neighbors, manual key distribution may be used. [I-D.behringer-tsvwg-rsvp-security-groupkeying] also discusses applicability of dynamic group key distribution method for dynamic update of such shared keys among RSVP routers. The RSVP Authentication mechanisms do not provide confidentiality. If confidentiality is required, IPsec ESP ([RFC4303]) may be used, although it imposes the burden of key distribution. It also faces Le Faucheur, et al. Expires June 16, 2008 [Page 20] C&C08 数字程控交换系统操作手册局数据分册目录 目录 第1章局数据配置总体说明....................................................................................................1-1 1.1 概述....................................................................................................................................1-1 1.2 局数据配置总体原则..........................................................................................................1-4 1.3 局数据配置一般注意事项...................................................................................................1-5 1.4 MML使用说明....................................................................................................................1-5 第1章 局数据配置总体说明 1.1 概述 C&C08交换机的数据配置，按照所配置数据的功能分为硬件配置数据、计费数据、中继数据、字冠数据、用户数据、智能数据，按照用户习惯分为局数据、用户数据和特殊业务数据。局数据包括上述的硬件配置数据、计费数据、中继数据和字冠数据，具体配置顺序如图1-1所示。在表1-1中列出了图中各个方框所代表的主要配置内容。 硬硬硬硬硬硬 计计硬硬 七七七七七七硬硬 七中中七七七七七硬硬V5七七硬硬 PRA 七七硬硬 智智硬硬 字字硬硬 普普普普硬硬 硬字普普硬硬 V5普普硬硬 结结 设硬设设七设 PRA 普普硬硬 Ephone 普普硬硬 图1-1 数据配置步骤 学习MCS-51单片机，如果用软件延时实现时钟，会接触到如下形式的延时子程序：delay:mov R5,#data1 d1:mov R6,#data2 d2:mov R7,#data3 d3:djnz R7,d3 djnz R6,d2 djnz R5,d1 Ret 其精确延时时间公式：t=（2*R5*R6*R7+3*R5*R6+3*R5+3）*T （“*”表示乘法，T表示一个机器周期的时间）近似延时时间公式：t=2*R5*R6*R7 *T 假如data1,data2,data3分别为50，40，248，并假定单片机晶振为12M，一个机器周期为10-6S，则10分钟后，时钟超前量超过1.11秒，24小时后时钟超前159.876秒（约2分40秒）。这都是data1,data2,data3三个数字造成的，精度比较差，建议C描述。 上表中e=-1的行（共11行）满足（2*R5*R6*R7+3*R5*R6+3*R5+3）=999，999 e=1的行（共2行）满足（2*R5*R6*R7+3*R5*R6+3*R5+3）=1，000，001 假如单片机晶振为12M，一个机器周期为10-6S，若要得到精确的延时一秒的子程序，则可以在之程序的Ret返回指令之前加一个机器周期为1的指令（比如nop指令）， data1,data2,data3选择e=-1的行。比如选择第一个e=-1行，则精确的延时一秒的子程序可以写成： delay:mov R5,#167 d1:mov R6,#171 d2:mov R7,#16 d3:djnz R7,d3 djnz R6,d2 djnz R5,d1 nop ；注意不要遗漏这一句 Ret 附： #include"iostReam.h" #include"math.h" int x=1,y=1,z=1,a,b,c,d,e(999989),f(0),g(0),i,j,k; void main() { foR(i=1;i<255;i++) { foR(j=1;j<255;j++) { foR(k=1;k<255;k++) { d=x*y*z*2+3*x*y+3*x+3-1000000; if(d==-1) { e=d;a=x;b=y;c=z; f++; cout<<"e="< 工地扬尘在线监测仪网页配置 工地扬尘在线监测仪主要由扬尘监测单元、噪声监测单元、气象监测单元、数据采集处理单元、数据传输单元、LED屏显示单元、视频字符叠加单元、数据展示平台组成，实现工地环境参数的监测、展示、数据上传、视频叠加功能，完美对接政府监测平台，从而实现工地环境参数的24小时监管。 1网页配置方法 1.1初次登录 1：设备提供两个功能完全相同的网口(LAN口)；配置时可以任意连接一个网口即可； 连接方式一:扬尘主机连接到本地局域网内的交换机或路由器时，用来配置扬尘主机的电脑也需要连接到该局域网内；如果该局域网内已经存在IP为192.168.1.252的设备，请使用连接方式二 连接方式二:将电脑使用一根网线直接连接到扬尘主机的网口；然后将自己电脑的IP配置为192.168.1.1网关配置为：192.168.1.1子网掩码配置为：255.255.255.0， 因针对不同的系统配置电脑IP的方式不一致，可以针对自己的系统通过百度配置电脑IP； 例如：使用的操作系统为win7系统，可以百度搜索：win7修改IP设置 2：设备连接电源，等到RUN灯亮起后； 3：打开浏览器，输入网址：192.168.1.252，出现以下界面；如果没有出现以下界面，几秒钟后重试； 4：输入默认用户名(admin)，密码(admin888)，点击登录；出现以下界面： 5：给该设备分配空闲有效的IP，及局域网的网关地址，DNS服务器和子网 掩码，点击“提交网络配置”；提示成功后，关闭电源即可，也可以直接进行后续操作，重启需要等待约1分钟； 1.2登录设备 1：设备上电； 2：解压之前下载过的文件，找到服务器搜索软件文件夹，进入，打开扬尘在线监测终端软件 3：点击”搜索设备”，会搜索所有在该局域网中的运行的设备 to与for的用法和区别 一般情况下, to后面常接对象; for后面表示原因与目的为多。 Thank you for helping me. Thanks to all of you. to sb.表示对某人有直接影响比如，食物对某人好或者不好就用to; for表示从意义、价值等间接角度来说，例如对某人而言是重要的，就用for. for和to这两个介词，意义丰富，用法复杂。这里仅就它们主要用法进行比较。 1. 表示各种“目的” 1. What do you study English for? 你为什么要学英语？ 2. She went to france for holiday. 她到法国度假去了。 3. These books are written for pupils. 这些书是为学生些的。 4. hope for the best, prepare for the worst. 作最好的打算，作最坏的准备。 2．对于 1．She has a liking for painting. 她爱好绘画。 2．She had a natural gift for teaching. 她对教学有天赋/ 3．表示赞成同情，用for不用to. 1. Are you for the idea or against it? 你是支持还是反对这个想法？ 2. He expresses sympathy for the common people.. 他表现了对普通老百姓的同情。 3. I felt deeply sorry for my friend who was very ill. 4 for表示因为，由于（常有较活译法） 1 Thank you for coming. 谢谢你来。 2. France is famous for its wines. 法国因酒而出名。 5．当事人对某事的主观看法，对于（某人），对…来说（多和形容词连用）用介词to，不用for.. He said that money was not important to him. 他说钱对他并不重要。 To her it was rather unusual. 对她来说这是相当不寻常的。 They are cruel to animals. 他们对动物很残忍。 6．for和fit, good, bad, useful, suitable 等形容词连用，表示适宜，适合。 Some training will make them fit for the job. 经过一段训练，他们会胜任这项工作的。 Exercises are good for health. 锻炼有益于健康。 Smoking and drinking are bad for health. 抽烟喝酒对健康有害。 You are not suited for the kind of work you are doing. 7. for表示不定式逻辑上的主语，可以用在主语、表语、状语、定语中。 1．It would be best for you to write to him. 2．The simple thing is for him to resign at once. 3．There was nowhere else for me to go. 4．He opened a door and stood aside for her to pass. 2011年台式电脑最佳组合配置 CPU AMD 速龙2 X4 635为主配置怎么组好？ 最佳答案： CPU AMD 速龙II X4 635 1 ￥665 主板华硕M4N68T 1 ￥495 内存威刚2GB DDR3 1333（万紫千红） 1 ￥315 硬盘WD 500GB 7200转16MB（串口/RE3） 1 ￥299 显卡昂达HD5770 1024MB 神戈 1 ￥999 光驱技嘉GO-D180SA 刻录机 1 ￥120 机箱动力火车217K 或517 1 ￥99 电源威盛超V王ATX-450WS 额定450W 1 ￥229 键鼠装自选 1 ￥60以内的 散热器超频三红海至尊版 1 ￥199 液晶显示器AOC 919Sw 1 ￥740 参考金额：4220元电脑城4300元左右 预算多可加一根内存条，组成4G双通道，性能更为出色，近乎完美。 标准3A平台：4核CPU、GDDR5芯片0.4NS 1G显存、450W额定供电…… 2011年台式电脑配置 我想攒一个台式机，价格大概要两千七八左右，请各位高手指点一下，大概什么配置！ 最佳答案 *CPU Intel 酷睿i5 760（盒） 1 ￥1360 Intel I5 原生4核心主频2.8GHz集成8M三级缓存，性能极其强大。根据驱动之家的CPU评测表明，4核的I5 750 在运行星际争霸2 的时候，如果显卡不成为瓶颈的话，他的表现在某些方面甚至比AMD的6核顶级1090T 还要更好，这表明Intel在中高端或高端的技术要强于AMD。加上Intel 公认的超高稳定性和兼容性强烈推荐。 *主板技嘉GA-H55M-D2H ￥690 一线主板厂商技嘉出品，采用H55芯片组，稳定和兼容更加出色，做工出色全固态电容品质保证你的稳定运行，带有HDMI接口，支持ATI CF交火技术性价比不错。 *内存OCZ DDR3 1333 4GB（2G×2条双通道套装）￥310 三大高端内存品牌之一，给你配了2G×2的DDR3 1333的4G双通道套装，OCZ 以超频性能出色闻名一贯品质出色做工精良，耐用性更好，性能更加出色稳妥的配备了散热片，整体做工讲究扎实。由于I5 CPU默认的是1333的内存控制器，所以不推荐1600的内存。 硬盘希捷1TB SATA2 32M 7200.12/ST310005 ￥390 希捷采用业界可靠性极高的成熟垂直磁记录技术，160MB/秒的最高可持续性数据传输率高达3Gb/秒的瞬间突发数据传输率32MB 缓存的1TB硬盘。如果不放心的话可以换：西部数据WD 1T 蓝盘。 显卡索泰GTX460-1GD5 毁灭者￥1350 N卡的龙头品牌，质量和做工都非常出色，显卡规格，显示频率700/3600MHZ 高于公版显存1G 256位GDDR5完整版，索泰独家研发的“V8直排式散热引擎”技术，通过增大散热鳍片面积和增加铜导热板来提升散热表现。游戏必须极其出色，全面压倒5830，轻松秒杀时下所有网络游戏，4开不卡。单机游戏的话分 建筑施工总体部署方案 施工部署 1、部署原则 1）、合理有效的利用现场一切资源。根据甲方提供的水、电源，合理敷设临时水、电，以保证生产、生活需要。 2）、根据现场情况及施工安排，结合考虑其他施工单位的出行，修建临时道路，保证施工的正常有序进行。 3）、根据工程需要和现场条件,在业主指定区域现场设置办公区、材料库等临时设施。 4）、在保证工程施工质量的前提下，合理安排施工顺序，在有限的工期内，合理配置资源，做到质量高、速度快。 2、总体部署 根据施工现场位置和条件，为保证施工进度的正常进行，施工采用分组施工的方法。依据本工程的特点，施工时按2个班组分别布置，分别组织施工，统一管理，统一协调。 室内和室外分为两个班组，根据总体施工计划及各班组实际施工情况，合理安排。临时水、电按业主总体安排就近接入作业区。由于管线施工中交插作业多，需与各专业施工队伍积极合作，及时调整施工部署，确保总体工期目的实现。 施工安排：各班组基本独立进行，充分发挥机械施工优势，详细制定落实工、料、机进场计划，优化施工顺序和工序安排施工。 3、施工组织体系 根据本工程施工分散、交叉处理多、施工单位间交叉作业等特点，组织强有力的项目经理部，配备各职能部门，做到准备充分，人员充足，相互协调，团结协作，职责分明，各负其责。选用实力强、经验多、管理严的施工队伍，另外专门组织水电维护、场容维护班组。 项目管理组织机构图 4.1、工期安排 4、施工组织安排 为保证工程的顺利进行和各项目目标的实现，我项目经理部有关人员将对本工程进行科学、合理的组织和管理，对工程的进度、质量、安全做好各种技术保证措施；对施工材料的使用、施工机具的安排等问题进行良好的部署和协调。 5、施工前准备工作 1）施工现场准备工作 （1）施工现场交通 本工程将修建交通便道进行物料运输，从而使本工程的交通较为便利。 X污水处理厂在线监测系统 配置内容及技术要求 一、建设内容：包括污水处理厂以下子系统 1、进、水口的COD在线监测系统各一套； 2、进、水口的氨氮在线监测系统各一套；（根据当地环保局要求可选）； 3、进、水口明渠超声波流量计子系统各一套。 4、数据采集传输系统各一套； 5、进、出水口监测设备用不间断供电（UPS）各一台； 6、进、出水口仪表间安装1.5P空调各一台；（用户自备） 7、进、出水口仪表间各一间；（土建） 8、进、出水口巴歇尔槽制作各一项；（土建） 9、配套管线材料二套。 二、符合相关规范及标准 GB11914－89 《水质化学需氧量测定重铬酸盐法》 HJ/T 15－2007 《环境保护产品技术要求超声波明渠污水流量计》HJ/T 377－2007 《环境保护产品技术要求化学需氧量（CODcr）水 质在线自动监测仪》 HJ/T 353－2007 《水污染源在线监测系统安装技术规范（试行）》HJ/T 354－2007 《水污染源在线监测系统验收技术规范（试行）》HJ/T 355－2007 《水污染源在线监测系统运行与考核技术规范（试 行）》 HJ/T 356－2007 《水污染源在线监测系统数据有效性判别技术规范 （试行）》 HJ/T 212 《污染源在线监控（监测）系统数据传输标准》ZBY120-83 《工业自动化仪表工作条件温度、湿度和大气压力》GB50168-92 《电气装置安装工程电缆线路施工及验收规范》GB50093-2002 《自动化仪表工程施工及验收规范》 三、采用设备技术要求及技术参数 1、仪器类型： ⑴进、出水口COD监测子系统要求采用重铬酸钾消解法，即重铬酸钾、硫酸银、浓硫酸等在消解池中消解氧化水中的有机物和还原性物质，比色法测定剩余的氧化剂，计算出COD值，在满足该方法基础上采用了能克服传统工艺的种种弊端的先进工艺和技术。 ⑵进、出水口流量监测要求可直接安装在室外明渠测量流量，采用超声波回波测距原理，并方便用户和环保主管部门的核对检查。 ⑶数据采集传输子系统要求符合HJ/T 212-2005标准，满足山西省环保厅关于环保监测数据传输技术要求的规定，并具有可扩展多中心传输的功能，模拟量信号采集通道不少于8个。 ⑷不间断电源功率应达3000VA，停电时可延时20分钟，二套。 ⑸进水口仪表间不小于8.4平米，巴歇尔槽符合出水流量要求。 2、主要设备技术参数 介词for用法归纳 用法1：(表目的)为了。如： They went out for a walk. 他们出去散步了。 What did you do that for? 你干吗这样做？ That’s what we’re here for. 这正是我们来的目的。 What’s she gone for this time? 她这次去干什么去了？ He was waiting for the bus. 他在等公共汽车。 【用法说明】在通常情况下，英语不用for doing sth 来表示目的。如： 他去那儿看他叔叔。 误：He went there for seeing his uncle. 正：He went there to see his uncle. 但是，若一个动名词已名词化，则可与for 连用表目的。如： He went there for swimming. 他去那儿游泳。(swimming 已名词化) 注意：若不是表目的，而是表原因、用途等，则其后可接动名词。(见下面的有关用法) 用法2：(表利益)为，为了。如： What can I do for you? 你想要我什么？ We study hard for our motherland. 我们为祖国努力学习。 Would you please carry this for me? 请你替我提这个东西好吗？ Do more exercise for the good of your health. 为了健康你要多运动。 【用法说明】(1) 有些后接双宾语的动词(如buy, choose, cook, fetch, find, get, order, prepare, sing, spare 等)，当双宾语易位时，通常用for 来引出间接宾语，表示间接宾语为受益者。如： She made her daughter a dress. / She made a dress for her daughter. 她为她女儿做了件连衣裙。 He cooked us some potatoes. / He cooked some potatoes for us. 他为我们煮了些土豆。 注意，类似下面这样的句子必须用for： He bought a new chair for the office. 他为办公室买了张新办公椅。 (2) 注意不要按汉语字面意思，在一些及物动词后误加介词for： 他们决定在电视上为他们的新产品打广告。 误：They decided to advertise for their new product on TV. 正：They decided to advertise their new product on TV. 注：advertise 可用作及物或不及物动词，但含义不同：advertise sth＝为卖出某物而打广告；advertise for sth＝为寻找某物而打广告。如：advertise for a job=登广告求职。由于受汉语“为”的影响，而此处误加了介词for。类似地，汉语中的“为人民服务”，说成英语是serve the people，而不是serve for the people，“为某人的死报仇”，说成英语是avenge sb’s death，而不是avenge for sb’s death，等等。用法3：(表用途)用于，用来。如： Knives are used for cutting things. 小刀是用来切东西的。 This knife is for cutting bread. 这把小刀是用于切面包的。 It’s a machine for slicing bread. 这是切面包的机器。 The doctor gave her some medicine for her cold. 医生给了她一些感冒药。 用法4：为得到，为拿到，为取得。如： He went home for his book. 他回家拿书。 He went to his friend for advice. 他去向朋友请教。 She often asked her parents for money. 她经常向父母要钱。 起名最佳三才配置 一一三 木木土 二二四 成功顺高，无障碍而向上发展，基础境遇也得安泰，终生享受繁荣长寿的吉配置。（吉）一一五 木木土 二二六 成功顺调，无障碍而向上发展，境遇坚实，如坐在磐石上，颇有安泰，能得幸福长寿而平安自在。（吉） 一一一 木木木 二二二 成功顺调，希望达成，基础安定，能向上发展，家门昌隆，心身健全，保得长寿大吉的配置。数凶者则有仇害之虑（吉） 一三一 木火木 二四二 得上下的惠助，顺调成功发展，基础强固，境遇安泰，子孙繁荣，心身健康而获得幸福及长寿的配置。（吉） 一三三 木火火 二四四 得顺调成功发展，但有缺乏耐久力的缺点。感为依靠性太强，招致失败，恐有陷于失意、病弱之兆。（半吉） 一三五 木火土 二四六 受上司的引进，得成功顺调发展，基础运又强固不动，心身均平安，能得长寿、幸福、理想的配置。（吉） 一五三 木土火 二六四 乏成功运，有不平不满的念头。难免犯呼吸器官和胃肠的疾患，但数理良好者，多有进展成功之配置。（半吉） 一九一 木水木 二十二 成功运佳，境遇又安定，配置吉。惟数理凶，故易遭病难、短命或家庭不幸等烦恼。（吉）一九七 一九九 木水水 虽可以成功于一时，但易生破乱，酿成灾变。或有病难和家庭的不幸，不过也有富豪长寿的可能。（半吉） 三一一 火木木 四二二 颇有向上发展的生机，目的容易达到而成功。基础、境遇俱佳而安泰，必定长寿享福，配置吉祥。（吉） 三一三 火木火 四二四 成功运佳，向上发展容易达到目的，基础、境遇俱属安泰，心身健康，得享长寿富荣。（吉） 三一五 火木土 四二六 向上进取，容易成功而富贵，基础犹如立足于磐石之上，巍然安泰，心身健全得长寿，配置大吉。（吉） 三三一 火火木 四四二 盛运隆昌，助者或共事者亦得一帆风顺而成功。基础稳固而安定，心身健全，得长寿享荣举，配置大吉。（吉） 施工总体部署 5.1施工管理目标 5.1.1质量目标 确保招标文件要求的质量目标实现，同时根据我单位综合实力，我们承诺： 质量标准：符合国家现行《工程施工质量验收规范》合格标准。 严格贯彻GB/T19001质量管理体系，保证“一次性验收合格”；确保“**杯”、“**杯”，争创“鲁班奖”。 5.1.2工期目标 开工日期：20xx年5月16日。 竣工日期：20xx年9月10日。 总工期：633日历天，完全响应招标文件的要求。(详见总工期横道图） 5.1.3安全文明施工目标 确保：不发生重大伤亡事故及机械伤害事故； 杜绝：重伤以上事故； 轻伤率：控制在6‰以内。 我单位将采取切实可行的措施和充足的安全投入，通过严密的安全管理，确保施工现场不发生重大伤亡事故、火灾事故及恶性中毒事件。创“省级安全施工标准化文明工地”。 5.2施工部署原则及要点 5.2.1部署原则 1、充分利用平面，组织流水施工的原则 根据施工图后浇带位分布位置，考虑异形结构尺寸，结构施工时将工作面划分施工段进行流失施工。 2、合理安排施工总平面，充分利用现场条件的原则 施工总平面的合理布置对于施工起着非常重要的作用，我们在现场布置时要充分利用现场条件，进行合理安排，尽量做到大型机械设备（如塔吊）不但能够覆盖到主体工程，而且能够覆盖到加工场、材料堆放场，提高大型机械设备的利用率。 3、用满时间，组织连续施工的原则 任何建设工程都是有时间限制的，任何优质的工程都是经过精雕细刻、花费大量时间施工出来的，在有限的时间内要做出优质工程，必须充分利用时间，组织连续、不间断的施工，才能达到即定工程目标。 4、人员部署，材料场外加工的原则 在本工程中，所有的临时设施都沿施工围挡进行修建，钢屋架的深化设计、施工等需要进行专业分包，钢屋架的制作和预拼装大部分需要在场外进行。玻璃幕墙的制作、安装也需要委托专业单位进行，所以玻璃幕墙的制作和其他准备工作也需要在场外进行。场内只布置部分构件的堆放场地和材料加工区域。 5、控制节点工期原则 C程序中可使用不同类型的变量来进行延时设计。经实验测试，使用unsigned char类型具有比unsigned int更优化的代码，在使用时 应该使用unsigned char作为延时变量。以某晶振为12MHz的单片 机为例，晶振为12M H z即一个机器周期为1u s。一. 500ms延时子程序 程序: void delay500ms(void) { unsigned char i,j,k; for(i=15;i>0;i--) for(j=202;j>0;j--) for(k=81;k>0;k--); } 计算分析: 程序共有三层循环 一层循环n:R5*2 = 81*2 = 162us DJNZ 2us 二层循环m:R6*(n+3) = 202*165 = 33330us DJNZ 2us + R5赋值 1us = 3us 三层循环: R7*(m+3) = 15*33333 = 499995us DJNZ 2us + R6赋值 1us = 3us 循环外: 5us 子程序调用 2us + 子程序返回2us + R7赋值 1us = 5us 延时总时间 = 三层循环 + 循环外 = 499995+5 = 500000us =500ms 计算公式:延时时间=[(2*R5+3)*R6+3]*R7+5 二. 200ms延时子程序 程序: void delay200ms(void) { unsigned char i,j,k; for(i=5;i>0;i--) for(j=132;j>0;j--) for(k=150;k>0;k--); } 三. 10ms延时子程序 程序: void delay10ms(void) { unsigned char i,j,k; for(i=5;i>0;i--) for(j=4;j>0;j--) for(k=248;k>0;k--); 第一节施工准备 一、外业准备 1、组织施工人员深入现场踏勘和作详细的调查研究，进一步了解施工现场的周围环境条件、施工条件、交通情况、水电供应情况、拆除旧材料场堆放位置，确定运输线路； 2、根据建设单位提供的图纸资料，结合现场踏勘所掌握的情况，弄清建筑物的结构情况、建筑情况、水电及设备管道情况； 3、临时用水在建设单位提供水源处敷设水源进入生活区、施工区； 4、清理被拆除建筑物倒塌范围内的物质、设备等，检查周围不拆的危旧房，必要时进行临时加固； 5、拆除建筑的四面均搭设篷布，将其全部密封，使灰尘影响降到最小，并在拆除危险区周围应设置安全警戒线及安全隔离禁区围栏、警戒标志，派专人监护，禁止非拆除人员进入施工现场； 6、向周围群众出安民告示，及时与周边及有关工程管理部门取得联系，经求得上述单位对拆除工程的支持； 7、切断、迁移影响拆除工程安全施工的各种水电管线，并确认全部切断后方可施工； 8、对拆除建筑外侧临近的架空线路和电缆线路，及时与有关部门取得联系，采取防护措施，确认安全后方可施工； 9、对拆除工程周围相邻的建（构）筑物、道路，先采取相应的保护措施，切实做好施工现场的防火措施。 二、内业准备 1、在拆除施工前，先熟悉拟拆除房屋工程的有关图纸和资料，详细了解拆除工程涉及区域的地上、地下建筑及设施分布情况资料； 2、编制分阶段、分专业的施工组织设计和安全保证计划及成本预算； 3、编制日作业计划，编制材料、劳动力、设备进场计划； 4、加强思想教育工作，树立管理者和施工人员良好的形象，从精神面貌、生活作风、施工环境保护、社会公德方面进行职工思想教育； 5、进一步深化施工方案，如编制施工劳动力各专业工程调配和优化等，并报批； 6、对拆除施工作业人员进行详细的书面安全技术交底。使被交底作业人员全面了解该项技术作业的基本要求和安全操作规程，在安全技术交底文件上签字，并接受安全管理人员的监督检查； 7、对拆除施工作业人员进行专门的安全作业培训，考试合格后方可上岗作业； 8、为拆除施工作业人员办理相关手续，签订劳动合同，办理意外伤害保险。 第二节组织机构、总体部署 一、组织机构 针对本拆除工程的特点和拆除工程周边环境的具体情况，为确保工期和安全，进一步加强工程管理，我们将充分发挥本公司在东莞基地的优势，以及以往所做的拆除工程施工管理经验，组织精干、熟练，有丰富经验的专业拆除施工队进场，密切配合施工现场、作好施工准备工作，加快拆除施工进度，安全高效地按合同要求完成本次拆除施工 一、关于单片机周期的几个概念 ●时钟周期 时钟周期也称为振荡周期，定义为时钟脉冲的倒数（可以这样来理解，时钟周期就是单片机外接晶振的倒数，例如12MHz的晶振，它的时间周期就是1/12 us），是计算机中最基本的、最小的时间单位。 在一个时钟周期内，CPU仅完成一个最基本的动作。 ●机器周期 完成一个基本操作所需要的时间称为机器周期。 以51为例,晶振12M，时钟周期(晶振周期)就是(1/12)μs，一个机器周期包 执行一条指令所需要的时间，一般由若干个机器周期组成。指令不同，所需的机器周期也不同。 对于一些简单的的单字节指令，在取指令周期中，指令取出到指令寄存器后，立即译码执行，不再需要其它的机器周期。对于一些比较复杂的指令，例如转移指令、乘法指令，则需要两个或者两个以上的机器周期。 1.指令含义 DJNZ：减1条件转移指令 这是一组把减1与条件转移两种功能结合在一起的指令，共2条。 DJNZ Rn，rel ；Rn←（Rn）-1 ；若（Rn）=0，则PC←（PC）+2 ；顺序执行 ；若（Rn）≠0，则PC←（PC）+2+rel，转移到rel所在位置DJNZ direct，rel ；direct←（direct）-1 ；若（direct）= 0，则PC←（PC）+3；顺序执行 ；若（direct）≠0，则PC←（PC）+3+rel，转移到rel 所在位置 2.DJNZ Rn,rel指令详解 例： MOV R7，#5 DEL:DJNZ R7,DEL; rel在本例中指标号DEL 1.单层循环 由上例可知，当Rn赋值为几，循环就执行几次，上例执行5次，因此本例执行的机器周期个数=1（MOV R7，#5）+2（DJNZ R7,DEL）×5=11，以12MHz的晶振为例，执行时间（延时时间）=机器周期个数×1μs=11μs，当设定立即数为0时，循环程序最多执行256次，即延时时间最多256μs。 2.双层循环 1）格式： DELL:MOV R7，#bb DELL1:MOV R6，#aa DELL2:DJNZ R6,DELL2; rel在本句中指标号DELL2 DJNZ R7,DELL1; rel在本句中指标号DELL1 注意：循环的格式，写错很容易变成死循环，格式中的Rn和标号可随意指定。 2）执行过程 变电站状态监测系统解决方案 许继昌南通信设备有限公司 2011.11 目录 1、配置表 (1) 2、系统整体方案 (1) 3、产品介绍 (2) 3.1GIS监测相关装置 (3) 3.2变压器监测相关装置 (6) 3.3开关柜监测装置 (10) 3.4避雷器在线监测系统 (14) 3.5站内状态监测主站系统 (14) 1、配置表 根据110kV及以上变电站设备配置监测设备如下： 2、系统整体方案 设备状态监测和诊断的关键是在线监测技术，在线监测技术是实现智能设备状态可视化的必要手段，是状态维修的实现基础，为其提供了实时连续的监测数据和分析依据。有效的在线监测系统可以随时掌握设备的技术状况和劣化程度，避免突发性事故和控制渐发故障的发生，从而提高高压电气设备的利用率，有助于从周期性、预防性维修向状态检修的转变，改善资产管理和设备寿命评估，加强故障原因分析。 在线监测、故障诊断、实施维修整个一系列过程构成了电气设备状态检修工作的内涵。因此，积极发展和应用变电站设备在线监测系统的最终目的就是为了以状态检修取代目前的定期维修，为其提供了分析诊断的依据，是状态维修策略不可或缺的组成部分。智能变电站监测总体方案如下图： IEC61850-8-1 IEC61850-8-1 智能组件 柜 变电站状态监测典型方案架构 状态监测系统系统结构 1）状态监测系统结构应为网络拓扑的结构形式，变电站内状态监测系统向上作为远方主站的网络终端，同时又相对独立，站内自成系统，层与层之间应相对独立，采用分层、分布、开放式网络系统实现各设备间连接。 2）站控层由状态监测系统综合平台组成，提供站内运行的人机界面，实现监视查看间隔层和过程层设备等功能，形成全站状态监测中心，并与远方主站状态监测系统进行通信。 3）间隔层由计算机网络连接的若干个综合数据集成单元组成（针对专业性较强，数据分析较为复杂的监测项目）。过程层由若干个监测功能组IED及状态监测传感器组成。 站控层综合数据单元均与过程层监测功能组主IED整合为状态监测IED，以减少装置数量，节约场地布置空间。过程层传感器由一次厂家成套。 4）状态监测IED采用IEC61850协议与站控层综合平台通信，各监测IED的评价结果通过站控层网络传输至综合平台，综合平台汇总并综合分析，监测数据文件仅在召唤时传送。 5）站控层综合平台设备与状态监测IED连接采用以太网，通信速率满足技术要求。 6）状态监测IED与过程层传感器的连接采用现场总线，通信速率满足技术要求。 For的用法 1. 表示“当作、作为”。如: I like some bread and milk for breakfast. 我喜欢把面包和牛奶作为早餐。 What will we have for supper? 我们晚餐吃什么? 2. 表示理由或原因,意为“因为、由于”。如: Thank you for helping me with my English. 谢谢你帮我学习英语。 3. 表示动作的对象或接受者,意为“给……”、“对…… (而言)”。如: Let me pick it up for you. 让我为你捡起来。 Watching TV too much is bad for your health. 看电视太多有害于你的健康。 4. 表示时间、距离,意为“计、达”。如: I usually do the running for an hour in the morning. 我早晨通常跑步一小时。 We will stay there for two days. 我们将在那里逗留两天。 5. 表示去向、目的,意为“向、往、取、买”等。如: Let’s go for a walk. 我们出去散步吧。 I came here for my schoolbag.我来这儿取书包。 I paid twenty yuan for the dictionary. 我花了20元买这本词典。 6. 表示所属关系或用途,意为“为、适于……的”。如: It’s time for school. 到上学的时间了。 Here is a letter for you. 这儿有你的一封信。 7. 表示“支持、赞成”。如: Are you for this plan or against it? 你是支持还是反对这个计划? 8. 用于一些固定搭配中。如: Who are you waiting for? 你在等谁? For example, Mr Green is a kind teacher. 比如,格林先生是一位心地善良的老师。 尽管for 的用法较多，但记住常用的几个就可以了。 to的用法: 一：表示相对，针对 be strange (common, new, familiar, peculiar) to This injection will make you immune to infection. 二：表示对比，比较 1：以-ior结尾的形容词，后接介词to表示比较，如：superior ,inferior,prior,senior,junior 2: 一些本身就含有比较或比拟意思的形容词，如equal，similar，equivalent，analogous A is similar to B in many ways. 新疆油田四2区供水管线建设工程工程建设项目总体部署 拟制人： 审核人： 审批人： 拟制时间： 中国石油集团工程设计有限责任公司 新疆设计院 1概述 为保障油田生产用水，同时考虑附近新增用户用水需求，支援地方发展，新疆油田公司决定实施新疆油田四2区供水管线建设工程。 新疆油田四2区供水管线建设工程建设规模：输水干线近期建设输水规模7×104m3/d，配水干线建设输水规模4.5×104m3/d。 根据新疆油田公司关于《新疆油田四2区供水管线建设工程》方案批复（油新计字〔2012〕78号）及初步设计的批复（油新计字〔2013〕36号），新疆油田公司决定于2013年建设投运新疆油田四2区供水管线。 主要建设内容：新建1条供水管线，以第五净化水厂为水源，途径市区东环路、迎宾路至四2区。其中DN1000球墨铸铁管15.13千米，DN800球墨铸铁管8.15千米。配套建设闸阀、土建、闸门井等。 本工程建设单位：新疆油田公司供水公司。 监理单位：新疆石油工程建设监理有限责任公司。 设计单位：新疆石油勘察设计研究院（有限公司）。 EPC总承包单位：新疆石油勘察设计研究院（有限公司）。 开、竣工日期：2013年7月15日-2013年11月20日。 2 总体方针及技术措施 本部署针对该工程内容，总体规划、合理部署。依据此方案科学合理的管理施工，确保工程质量和工期。 认真贯彻国家和上级有关方针、政策及油田公司、院的各项规章制度，维护企业利益，确保各项经济技术指标完成。对项目工程进度、质量、安全、计价、材料等实行全过程的管理，为实现以上目标负全责。科学管理进入项目工程的人、财、物资源，协调关系，理顺人员、物力和机械设备的调配与供应，及时解决施工中出现的问题。监督项目按图施工，及时解决施工中的技术难点。组织有关人员会审设计文件，组织科研成果的实践，审定QC 项目，参与质量事故的原因调查，处理质量事故的技术问题。 1.两者都可以引出间接宾语，但要根据不同的动词分别选用介词to 或for：(1) 在give, pass, hand, lend, send, tell, bring, show, pay, read, return, write, offer, teach, throw 等之后接介词to。 如： 请把那本字典递给我。 正：Please hand me that dictionary. 正：Please hand that dictionary to me. 她去年教我们的音乐。 正：She taught us music last year. 正：She taught music to us last year. (2) 在buy, make, get, order, cook, sing, fetch, play, find, paint, choose,prepare, spare 等之后用介词for 。如： 他为我们唱了首英语歌。 正：He sang us an English song. 正：He sang an English song for us. 请帮我把钥匙找到。 正：Please find me the keys. 正：Please find the keys for me. 能耽搁你几分钟吗(即你能为我抽出几分钟吗)? 正：Can you spare me a few minutes? 正：Can you spare a few minutes for me? 注：有的动词由于搭配和含义的不同，用介词to 或for 都是可能的。如：do sb a favour＝do a favour for sb 帮某人的忙 do sb harm＝do harm to sb 对某人有害 施工总体部署方案1.1 项目管理组织 1.1.1项目组织机构图（略） 1.1.2 项目部各部门工作职责和权限 项目部各部门及人员职责严格按照局企业标准执行。 1.2 总承包管理 1.2.1 总承包管理组织、策划、实施 施工总承包项目经理部肩负实施项目管理、履行施工总承包合同的重任，是企业为实现本工程各项管理目标而设置的施工现场管理组织。项目经理部代表我局按“公正”、“科学”、“统一”、“控制”、“协调”的原则实行总承包组织、策划、实施。 1.2.2 对专业工程管理范围及服务承诺 根据业主要求，结合本工程特点，我局主要负责施工土建主体结构和安装水、电预留预埋工作，为了加强项目施工对土建专业和安装的管理力量，我局设立的现场项目经理部，代表我局履行合同义务，对专业分包进行统一管理、统一协调，确保各分项工程目标的实现，直接对业主和监理负责。 1.2.3 局总部与现场项目管理部的关系和授权 局总部与现场项目管理组织的关系，可概括为十六字，即“总部监督，部门协助，授权管理，全面负责”。 1.2.1.1 “总部监督”是指局总部按合同要求和承诺，对项目部的实施情况进行全程监督，必要时调动全局的人力、物力，确保合同要求和承诺全面兑现。 1.2.1.2 “部门协助”是指局总部的工程、技术、质量、安全、财务、预算等各业务部门对项目提供人、财、物的全方位支持，各部门对项目的管理以服务为主，监督为辅。 1.2.1.3 “授权管理”是指局总部授权于项目经理对本工程及与本工程有关的事宜进行管理，包括对人、财、物的支配调动权，奖罚权。 1.2.1.4 “全面负责”是指项目部全面履行合同要求和承诺，对本工程一切施工活动包括工期、质量、安全、成本、文明施工等全面负责并组织落实。 1.2.4 分包管理组织机构的设置及职责； 1.2.4.1 各专业分包单位进入施工现场前，均需按总包管理办法的要求设置相应的组织管理机构配置对口的管理人员。 1.2.4.2 进入施工现场的各专业分包单位按总包设置好的机构统一命名，其命名规则为：山东广播电视中心综合业务楼工程XX项目经理部 1.2.4.3 信函及有关文件需标注单位名称时，一律以总包确定的名称为准。 1.2.4.4 各专业分包单位必须按照总包设置的机构和管理岗位配齐相应的管理人员。 1.2.4.5 分包单位必须具备本工程施工单项注册或济南市的施工注册执照，01-第1章 局数据配置总体说明
延时子程序计算方法
建筑工地扬尘在线监测仪网页配置方法
to与for的用法和区别
台式电脑最佳组合配置
建筑施工总体部署方案
污水处理厂在线监测系统配置要求
(完整版)介词for用法归纳
起名必备最佳三才配置
施工总体部署(机械及劳动力配置)
单片机C延时时间怎样计算
(完整版)施工准备及总体部署
51单片机延时时间计算和延时程序设计
变电站在线监测配置方案
常用介词用法(for to with of)
工程建设项目总体部署
双宾语 to for的用法
施工总体部署方案
相关主题
文本预览