Load Balancing 실패시.. T_T
모니터는 두개로 늘어 났지만 그만큼 늘어난 업무와 정리 안되는 아이콘들..
A statement of work (SOW) is a document used in the Systems Development Life Cycle. A software vendor or services company will send a SOW to notify a client of work about to be undertaken and agreed pricing. It is a brief summary of financial aspects of a contract; the technical details should have already been fleshed out by this stage.
Certain areas that need to be addressed are as follows:
Scope of Work, This describes the work to be done in detail
and specifies the hardware and software involved and the exact nature
of the work to be done.
Location of Work, This describes where the work is to be
performed. This also specifies the location of hardware and software
and where people will meet to perform the work.
Period of Performance, This specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.
Deliverables Schedule, This part lists the specific deliverables, describing what is due and when.
Applicable Standards, This describes any industry specific standards that need to be adhered to in fulfilling the contract.
Acceptance Criteria, This specifies how the buyer or receiver of goods will determine if the product or service is acceptable, what criteria will be used to state the work is acceptable.
Special Requirements. This specifies any special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.
템플릿 첨부
몇일전에 친한 친구하고 전화 통화를 하다가 있던 일이다..
그 친구도 앞으로 뭘 해야 할지 걱정이라면서 ?이것 저것 이야기가 오고 가다가...
더 공부 하고 싶어 하는 분야가 있다고 하여
내가 "그럼 너도 대학원 와서 좀더 공부 하지 그래?" 라고 물었다
그때 ?그 친구의 왈 " 난 시간도 별로 없고, 돈도 별로 없어서...."
헉~ 뭐 본의는 아니
이럴줄 알았으면....학부때 토익 대신 C 언어 공부나 할껄...
터미널의 화면 만큼이나 깜깜하다....
There is considerable evidence that mobility for IP nodes can be more efficiently handled if mobility management is broken down into localized mobility management and global mobility management.
로컬하게나 글로벌 하게 모빌리티를 관리하면 IP노드에 대한 좀더 효과적인 관리가 가능하다.
Local mobility involves movements across some administratively and geographically contiguous set of subnets, while global mobility involves movements across broader administrative, geographical, and topological domains.
로컬 모빌리티는 서브넷 상의 행정 구역이나 지역적인 곳에서의 이동은 의미한다. 반변, 글로벌 모빌리티는 topological domains 상의 더 넓은 행정구역이나 지역적 공간에서의 이동을 의미한다.
Previous work in the IETF has focused on supporting localized mobility management for a Mobile IPv6 node, and the protocols developed have required mobile node-side support at the IP layer.
기존의 IETF의 작업들은 Mobile IPv6노드들을 위한 지역적인 모빌리티 관리에만 초점을 맞추어 왔다, 그리고 프로토콜의 개발도 IP layer에서의 이동노드지원에 초점을 맞추어 왔다.
Recently in the IETF, new work on global mobility management approaches other than Mobile IPv6 suggests that a localized mobility management approach decoupled(결합을 없애다) from the global mobility management protocol might result in a more modular mobility management system design and therefore more longevity(장수) and an easier evolution(진화) path.
In the WLAN infrastructure market, WLAN switches, which perform localized mobility management without any mobile node involvement, have seen widespread deployment, indicating the technical feasibility and positive user acceptance of this approach.
without any mobile node involvement한 지역적 모빌리티 관리로 동작하는 WLAN 스위치같은 WLAN 인프라 마켓은 기술력과 사용자의 긍정적인 반응으로 널리 구현되어 있다.
This suggests a design paradigm that could be used to accommodate global mobility management protocols of different types while not increasing software complexity: a network-based, localized mobility protocol with no mobile node software to specifically implement localized mobility management and no requirement for a network interface to change IP address when the mobile node changes to a new router.
design paradigm은 소프트웨어적 복잡함의 증가 없이도
The task of the NETLMM Working Group is to design a protocol solution for network-based localized mobility management.
The network-based localized mobility management protocol will conform to the following framework. Mobility anchor points within the backbone network maintain a collection of routes for individual mobile nodes.
The routes point to the access routers on which mobile nodes currently are located.
Packets for the mobile node are routed to and from the mobile node through the mobility anchor point.
When a mobile node moves from one access router to another, the access routers send a route update to the mobility anchor point.
While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the access router about mobile node movement, no specific mobile node to network protocol will be required for localized mobility management itself.
The working group will develop a protocol between the access routers and mobility anchor points that minimally has the following functions:
- Handles a new mobile node that powers on or moves from another
localized mobility management domain, or an existing mobile node that
shuts down without any notice (i.e. crashes),
- Handles routing update when a mobile node moves from one access
router to another within the localized mobility management domain,
The necessity for additional protocol functions may arise during
Working Group discussions, so this list should not be taken as final.
The protocol will be independent of any particular global mobility
management protocol, and it will be link-layer agnostic by running on
top of IP. The protocol itself will be agnostic with respect to the
last hop link layer protocol between the mobile node and the access
router. Adaptation of the protocol to different kinds of last hop link
layers is accomplished through an interface on the access router
common to all link layers under which specific link layer mechanisms
(possibly together with authentication mechanisms) can provide a
reliable handover indication and unique identity for the mobile node.
This will enable the access router to do a route update using NETLMM
on behalf of the mobile node. In addition to the NETLMM protocol
document, the Working Group will produce an informational document
that describes how existing and developing IETF standards for node to
access router communication on the local link can be used to accomplish
secure triggering of route update. This document will be informational
only, because some link protocols are expected to provide their own
mechanisms.
The scope of the work is initially limited to IPv6 both in the backbone
and on the edges, and is primarily for networks covering larger
geographical regions such as multiple corporate campuses and
metropolitian areas. The protocol will not attempt to hide handover
between two separate interfaces on the mobile node. The protocol will
not define a new tunneling protocol but will reuse existing IP
tunneling mechanisms if necessary. The NETLMM protocol will maintain
compatibility with other IETF standards, both existing and developing,
such as DNS, DNA, and global mobility protocols such as Mobile IPv6
and NEMO Basic Support.
Security between access routers and the mobility anchor will be defined
for the protocol based on an IETF-approved threat model giving
preference to existing security solutions where applicable. The threat
model will be described in a document delivered sufficiently in
advance of completion of the protocol design that the protocol design
can accommodate mitigation measures. In addition, the mobile node to
router interface document will describe threats to the protocol when
the default, IP-level mobile node to router protocol is used, and will
prescribe how existing security protocols are used to counter the
threats.
The Working Group has the following deliverables:
- A problem statement document that clearly and succinctly describes
the problem posed by localized mobility management and why a
network-based approach is desirable,
- A requirements and gap analysis that examines a selection of
existing IETF protocols, particularly within the mobility space, for
applicability as a solution. If a proposed protocol is insufficient as
a solution, the reasons why will be clearly stated.
- A threat model draft that describes the threats to a netlmm
protocol, based on the framework described in this charter, and how
the threats can be mitigated giving preference to existing security
solutions where applicable.
- A protocol design for an interoperable, scalable network-based
localized mobility management protocol between the access routers and
the mobility anchor point including security for the access router to
mobility anchor interface,
- A document describing how existing or developing IETF protocol
standards can be used between the access router and the mobile node to
inform the access router about the arrival of a mobile node, for use
when the wireless link protocol does not provide support for this
function. This document will also discuss threats and security
countermeasures for mobile node identification.
Out of scope for the first design are: route optimization, inter-access
router tunneling to optimize handover, mechanisms for handover between
localized mobility management domains (other than standard global
mobility management protocols), IPv4 support, and multiple mobility
anchor points. During the design process, these enhancements will be
kept in mind, but actual work to incorporate them or other
enhancements will be deferred until after the initial design is
complete and the working group recharters.

洹몃